mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "wangwensheng (C)" <wangwensheng4@huawei.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: "wim@linux-watchdog.org" <wim@linux-watchdog.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Xiangrui (Euler)" <rui.xiang@huawei.com>,
	"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>
Subject: Re: [PATCH -next v3 1/2] watchdog: Fix potential dereferencing of null pointer
Date: Fri, 6 Nov 2020 07:37:08 +0000	[thread overview]
Message-ID: <4a85d0170a69430585fb89aba7490d9a@huawei.com> (raw)
In-Reply-To: <20201105142621.GB1389@roeck-us.net>

在 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 <wangwensheng4@huawei.com>
>> ---
>>   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
>>
> 


  reply	other threads:[~2020-11-06  7:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-05 12:38 Wang Wensheng
2020-11-05 12:38 ` [PATCH -next v3 2/2] watchdog: Clean up error handlings Wang Wensheng
2020-11-05 14:26 ` [PATCH -next v3 1/2] watchdog: Fix potential dereferencing of null pointer Guenter Roeck
2020-11-06  7:37   ` wangwensheng (C) [this message]
2020-11-06 13:19     ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4a85d0170a69430585fb89aba7490d9a@huawei.com \
    --to=wangwensheng4@huawei.com \
    --cc=guohanjun@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=rui.xiang@huawei.com \
    --cc=wim@linux-watchdog.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®