Re: [PATCH] watchdog: shwdt: register device only after full driver init

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing timer synchronization in `sh_wdt_remove` leads to a use-after-free when the `wdt` structure is automatically freed.
- [High] Calling non-synchronous `timer_delete` while holding `wdt->lock` in `sh_wdt_stop` allows the timer callback to execute concurrently, accessing suspended hardware and re-arming itself.
- [High] `sh_wdt_start` ignores the return values of `pm_runtime_get_sync` and `clk_enable`, potentially accessing hardware registers while powered down.
--

commit f766a8cc3f43e37c436ed7a87ffc702a473f6839
Author: Cong Nguyen <congnt264@gmail.com>

watchdog: shwdt: register device only after full driver init
    
sh_wdt_probe() calls watchdog_register_device() -- exposing
/dev/watchdogN -- before timer_setup() and pm_runtime_enable() run. A
start command landing in that window calls mod_timer() on an
uninitialized timer (NULL ->function) and resumes via
pm_runtime_get_sync() before PM is enabled.
    
Move timer_setup() and pm_runtime_enable() before the register call,
matching the order already used by rzg2l_wdt.c/rzv2h_wdt.c. Add
pm_runtime_disable() on the now-possible post-enable register-failure
path.

> diff --git a/drivers/watchdog/shwdt.c b/drivers/watchdog/shwdt.c
> index 719f100aae60d..c22b8e7604765 100644
> --- a/drivers/watchdog/shwdt.c
> +++ b/drivers/watchdog/shwdt.c
> @@ -263,19 +263,20 @@ static int sh_wdt_probe(struct platform_device *pdev)
>  	dev_info(&pdev->dev, "configured with heartbeat=%d sec (nowayout=%d)\n",
>  		 sh_wdt_dev.timeout, nowayout);
>  
> +	timer_setup(&wdt->timer, sh_wdt_ping, 0);
> +	wdt->timer.expires	= next_ping_period(clock_division_ratio);
> +
> +	pm_runtime_enable(&pdev->dev);
> +
>  	rc = watchdog_register_device(&sh_wdt_dev);
>  	if (unlikely(rc)) {
>  		dev_err(&pdev->dev, "Can't register watchdog (err=%d)\n", rc);
> +		pm_runtime_disable(&pdev->dev);
>  		return rc;
>  	}
>  
> -	timer_setup(&wdt->timer, sh_wdt_ping, 0);
> -	wdt->timer.expires	= next_ping_period(clock_division_ratio);
> -
>  	dev_info(&pdev->dev, "initialized.\n");
>  
> -	pm_runtime_enable(&pdev->dev);
> -
>  	return 0;
>  }

[Severity: High]
This is a pre-existing issue, but missing timer synchronization in
sh_wdt_remove() could lead to a use-after-free when the wdt structure is
automatically freed:

drivers/watchdog/shwdt.c:sh_wdt_remove() {
	watchdog_unregister_device(&sh_wdt_dev);

	pm_runtime_disable(&pdev->dev);
}

If the driver is unbound while the watchdog timer is active, sh_wdt_remove()
completes and returns without stopping or synchronizing the timer. The devres
framework then immediately frees the wdt structure allocated via
devm_kzalloc().

Could the lingering asynchronous timer eventually fire and dereference the
freed memory in sh_wdt_ping()? Would it be safer to explicitly stop and
synchronize the timer here before returning?

[Severity: High]
This isn't a bug introduced by this patch, but calling non-synchronous
timer_delete() while holding wdt->lock in sh_wdt_stop() allows the timer
callback to execute concurrently:

drivers/watchdog/shwdt.c:sh_wdt_stop() {
...
	spin_lock_irqsave(&wdt->lock, flags);

	timer_delete(&wdt->timer);

	csr = sh_wdt_read_csr();
	csr &= ~WTCSR_TME;
	sh_wdt_write_csr(csr);

	spin_unlock_irqrestore(&wdt->lock, flags);

	clk_disable(wdt->clk);
	pm_runtime_put_sync(wdt->dev);
...
}

If sh_wdt_ping() runs on CPU 1 just as sh_wdt_stop() runs on CPU 0, CPU 1
blocks on wdt->lock. CPU 0 calls timer_delete(), disables the clock,
drops the lock, and calls pm_runtime_put_sync().

CPU 1 then acquires the lock and continues execution in sh_wdt_ping():

drivers/watchdog/shwdt.c:sh_wdt_ping() {
...
		csr = sh_wdt_read_csr();
		csr &= ~WTCSR_IOVF;
		sh_wdt_write_csr(csr);

		sh_wdt_write_cnt(0);

		mod_timer(&wdt->timer, next_ping_period(clock_division_ratio));
...
}

Can this sequence allow CPU 1 to access the now unclocked and suspended
hardware registers, and then call mod_timer() to blindly re-arm the callback?
Note that simply changing timer_delete() to timer_delete_sync() inside the
spinlock would cause a deadlock against the callback.

[Severity: High]
This is a pre-existing issue, but sh_wdt_start() ignores the return values of
pm_runtime_get_sync() and clk_enable():

drivers/watchdog/shwdt.c:sh_wdt_start() {
...
	pm_runtime_get_sync(wdt->dev);
	clk_enable(wdt->clk);

	spin_lock_irqsave(&wdt->lock, flags);
...
}

If either fails, the device remains suspended or unclocked, but the code
proceeds to read and write to wdt->base.

Could this result in a bus fault due to accessing unclocked or powered-down
hardware if power or clock management fails when the device is opened?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914123609.2186477-1-congnt264@gmail.com?part=1