Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1076884pxb; Thu, 5 Nov 2020 23:39:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJzTFxc6X+qw8wSoy8exlChP0nCchcXWZ5mQawazNMacxCIqQ6K96E8lb/ZeRtv+tCp7WuPu X-Received: by 2002:a50:fd8b:: with SMTP id o11mr756967edt.156.1604648341396; Thu, 05 Nov 2020 23:39:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604648341; cv=none; d=google.com; s=arc-20160816; b=d9RFn/JNIBLdd2E7Brxf7+vtO1UkrWpGBTmNMrkJnjnXeYDpeWsj2x7qVYQipym9kC rLYINBgXb9neW2GI6p4iu8rUEDBrh4gIiBfQCfmaIVnbsXceNP6wVDxWr8G66ROhXWFe pTZ0MNYqjxYIk5jyKikR/bXr3lbUQBUlsXYhVbNANvdq8LshEH8qEjq4pAfNPjSN4oTk ytCQx13Irsw4wAGFRAYwG/YuTzN16fEm1l2JouMAwY2ciYGH9XKtyXsN1XnIu1kSb5cr lVW4hAKscQ7S/hPHckTpBwBBy/zEIyquI0yIOZQY06r59l7kW0EG8wbGndSJ0Pnz9mVL YR9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :content-language:accept-language:references:message-id:date :thread-index:thread-topic:subject:cc:to:from; bh=/kx0fW8jDFUhGBchzZnDx1yzF9o8OKzpFQdF4tqLwP0=; b=1EOxYJi+4k1HDDwLtaWl12wYdxSmJiE5HdtaN6L/ew+dILOcQegOriK+/TYz8QD0Wo eJ4YpZmBFZnWVrW/NiDMcts3NMIUuNV/lFlJctDObmYQz2ptEgI8mGwm8gybyyMmJpEV Ft/dQZpjbw/mhW1lDrti4if8+iKfJ+TI4FafA7n7Fhu2l5rVepAW4twS4PHFvnVWAkhI sYn9AU0EVTogFdfhm0qOe44X+QDlqYmOEcFctlMwcgZlkf4veC/mmBQaIPffvX1SSKF7 hMe6lUfIh+wJ7uYUzV7ljhH9n2YCTS/tKiAgwIRXW3MvwOhGu4GhTjxtyS7ACKgwamjh NQyg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bm13si371384edb.281.2020.11.05.23.38.38; Thu, 05 Nov 2020 23:39:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726439AbgKFHhM convert rfc822-to-8bit (ORCPT + 99 others); Fri, 6 Nov 2020 02:37:12 -0500 Received: from szxga03-in.huawei.com ([45.249.212.189]:2364 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726050AbgKFHhM (ORCPT ); Fri, 6 Nov 2020 02:37:12 -0500 Received: from dggeme709-chm.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4CSBzf4Zbkz51hX; Fri, 6 Nov 2020 15:37:02 +0800 (CST) Received: from dggeme762-chm.china.huawei.com (10.3.19.108) by dggeme709-chm.china.huawei.com (10.1.199.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 6 Nov 2020 15:37:08 +0800 Received: from dggeme762-chm.china.huawei.com ([10.8.68.53]) by dggeme762-chm.china.huawei.com ([10.8.68.53]) with mapi id 15.01.1913.007; Fri, 6 Nov 2020 15:37:08 +0800 From: "wangwensheng (C)" To: Guenter Roeck CC: "wim@linux-watchdog.org" , "linux-watchdog@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Xiangrui (Euler)" , "Guohanjun (Hanjun Guo)" Subject: Re: [PATCH -next v3 1/2] watchdog: Fix potential dereferencing of null pointer Thread-Topic: [PATCH -next v3 1/2] watchdog: Fix potential dereferencing of null pointer Thread-Index: AQHWs3CwBqSD3b7850ugh4qmoAri0A== Date: Fri, 6 Nov 2020 07:37:08 +0000 Message-ID: <4a85d0170a69430585fb89aba7490d9a@huawei.com> References: <20201105123848.93735-1-wangwensheng4@huawei.com> <20201105142621.GB1389@roeck-us.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.174.176.77] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2020/11/5 22:26, Guenter Roeck 写道: > On Thu, Nov 05, 2020 at 12:38:47PM +0000, Wang Wensheng wrote: >> A reboot notifier, which stops the WDT by calling the stop hook without >> any check, would be registered when we set WDOG_STOP_ON_REBOOT flag. >> >> Howerer we allow the WDT driver to omit the stop hook since commit >> "d0684c8a93549" ("watchdog: Make stop function optional") and provide >> a module parameter for user that controls the WDOG_STOP_ON_REBOOT flag >> in commit 9232c80659e94 ("watchdog: Add stop_on_reboot parameter to >> control reboot policy"). Together that commits make user potential to >> insert a watchdog driver that don't provide a stop hook but with the >> stop_on_reboot parameter set, then dereferencing of null pointer occurs >> on system reboot. >> >> Check the stop hook before registering the reboot notifier to fix the >> issue. >> >> Fixes: d0684c8a9354 ("watchdog: Make stop function optional") >> Signed-off-by: Wang Wensheng >> --- >> drivers/watchdog/watchdog_core.c | 9 ++++++++- >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c >> index 423844757812..945ab38b14b8 100644 >> --- a/drivers/watchdog/watchdog_core.c >> +++ b/drivers/watchdog/watchdog_core.c >> @@ -267,8 +267,15 @@ static int __watchdog_register_device(struct watchdog_device *wdd) >> } >> >> if (test_bit(WDOG_STOP_ON_REBOOT, &wdd->status)) { >> - wdd->reboot_nb.notifier_call = watchdog_reboot_notifier; >> + if (!wdd->ops->stop) { >> + pr_err("watchdog%d: Cannot support stop_on_reboot\n", >> + wdd->id); >> + watchdog_dev_unregister(wdd); >> + ida_simple_remove(&watchdog_ida, id); >> + return -EINVAL; >> + } > > The problem with this is that setting the "stop_on_reboot" module parameter > would now prevent the watchdog from being loaded, which isn't really > desirable and might go unnoticed. I think the initial check should be > above, with the "Mandatory operations" check, and > if (stop_on_reboot != -1) { > should be extended to > if (stop_on_reboot != -1 && wdd->ops->stop) { > > or possibly more fancy: > > if (stop_on_reboot != -1) { > if (stop_on_reboot) { > if (!wdd->ops->stop) > pr_warn("watchdog%d: stop_on_reboot not supported\n", wdd->id); > else > set_bit(WDOG_STOP_ON_REBOOT, &wdd->status); > } else { > clear_bit(WDOG_STOP_ON_REBOOT, &wdd->status); > } > } > > Thanks, > Guenter Now the divergence is that should we stop the registering process and return error when the STOP_ON_REBOOT flag is set but the driver doesn't support it. The flag is set in two scenes. Firstly,the driver that should provide the stop hook may set the flag staticlly, and it is a bug of the driver if it set the flag but without a stop hook. Then giving an error shall be more striking. Secondly, the user can change the flag using module parameter. Is it reasonable to just ignore the STOP_ON_REBOOT flag and give a warning when the user truely want it? And under this circumstance a warning is easier to get unnoticed than an error. I prefer to stop the registering process and return an error in those two scenes. Thanks > >> >> + wdd->reboot_nb.notifier_call = watchdog_reboot_notifier; >> ret = register_reboot_notifier(&wdd->reboot_nb); >> if (ret) { >> pr_err("watchdog%d: Cannot register reboot notifier (%d)\n", >> -- >> 2.25.0 >> >