CVE-2026-97969: watchdog: msc313e: Fix clock leak and spurious timer in settimeout()
In the Linux kernel, the following vulnerability has been resolved:
watchdog: msc313e: Fix clock leak and spurious timer in settimeout()
msc313ewdtsettimeout() unconditionally calls msc313ewdtstart() which introduces two severe bugs:
1. If the watchdog is already active, calling start() again will increase the reference count of the clock again. However stop() is only called once, the reference count is unbalance. 2. If the watchdog is stopped, calling settimeout() will start the hardware timer accidentally.
Factor out the register-writing logic into a helper function. Only call it in settimeout() if the watchdog is running. Otherwise, simply update wdev->timeout.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel MSC313e watchdog driver are exposed when watchdog timeout settings are changed. The issue concerns the driver's settimeout() behavior, particularly when the watchdog is already active or stopped.
What happens when the timeout is changed while the watchdog is running?
The prior behavior calls the watchdog start routine again, increasing the clock reference count each time settimeout() is used. Because stopping the watchdog releases the clock only once, this leaves the clock reference count unbalanced.
Can changing the timeout start a watchdog that was intentionally stopped?
Yes. In the affected behavior, settimeout() unconditionally starts the hardware timer, so changing the timeout while the watchdog is stopped can accidentally activate it.
What does the fix change?
The fix separates hardware register programming from starting the watchdog. It updates timer registers only when the watchdog is already running; when stopped, it only updates the configured timeout value.