CVE-2026-74687 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
watchdog: at91sam9_wdt: prevent timer rearm during teardown
at91_ping() rearms the watchdog timer from its callback. timer_delete() neither waits for a running callback nor prevents it from rearming the timer, so probe failure or driver removal can leave the timer accessing the devm-allocated at91wdt after it has been freed.
Use timer_shutdown_sync() on both teardown paths. It waits for a running callback and rejects any attempt by the callback to rearm the timer.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability identified in the Linux kernel's watchdog subsystem, specifically within the at91sam9_wdt driver, represents a critical race condition arising from improper synchronization during device teardown operations. This flaw is rooted in the interaction between the hardware watchdog timer mechanism and the kernel’s dynamic memory management system for devices using managed resources (devm). The core issue lies in the behavior of standard timer deletion functions when dealing with asynchronous callbacks that may attempt to rearm or restart timers after a stop command has been issued but before the callback execution has fully completed. In this specific context, the at91_ping function serves as the watchdog keep-alive mechanism, which is invoked periodically by a hardware timer interrupt handler. When the driver undergoes removal due to probe failure or explicit unloading, the system attempts to clean up allocated resources. However, if the standard timer_delete API is used without ensuring that any running callback has finished executing, there exists a window where the watchdog timer might still be active and capable of invoking its callback function even after the associated device structure has been freed from memory.
This race condition leads directly to use-after-free vulnerabilities, which are among the most dangerous classes of software defects in systems programming. When the at91_ping callback executes after the devm-allocated at91wdt structure has been deallocated, it attempts to access invalid or recycled memory addresses. Depending on how quickly the kernel reuses that freed memory for other purposes, this can result in data corruption, unpredictable system behavior, or a complete kernel panic leading to a denial of service. In more severe scenarios where an attacker can influence the timing of driver removal and subsequent memory allocation patterns, such use-after-free conditions could potentially be exploited to achieve arbitrary code execution with kernel privileges. The lack of synchronization between the timer shutdown process and the callback lifecycle creates a classic time-of-check-to-time-of-use (TOCTOU) scenario, albeit in the temporal domain rather than file system paths.
From a classification perspective, this vulnerability aligns closely with CWE-416: Use After Free, as it involves accessing memory after it has been freed due to insufficient synchronization during resource cleanup. It also relates to CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition), specifically regarding the lack of atomicity in stopping the timer and freeing its associated data structures. In terms of the MITRE ATT&CK framework, this flaw could be leveraged within techniques such as T1059 Command and Scripting Interpreter or T1203 Exploitation for Client Execution if an attacker can trigger driver removal under controlled conditions to exploit the memory corruption state. The vulnerability highlights a common pitfall in kernel development where developers assume that stopping a timer immediately prevents all future invocations of its callback, ignoring the asynchronous nature of interrupt handlers and softirqs that may already be queued or executing on different CPU cores.
The resolution implemented by the Linux kernel maintainers addresses this issue by replacing standard timer deletion calls with timer_shutdown_sync(). This function is specifically designed to handle complex teardown scenarios in drivers that rely on timers for periodic tasks. Unlike simple deletion functions, timer_shutdown_sync() ensures two critical guarantees: first, it waits for any currently running callback associated with the timer to complete its execution before proceeding; second, it disables further rearming of the timer by subsequent interrupt events or internal logic within the driver. By enforcing this synchronization barrier during both probe failure and driver removal paths, the kernel prevents the watchdog hardware from triggering a callback that would reference freed memory structures. This approach ensures that the device state is fully quiesced before any resources are released to the system allocator.
To mitigate similar vulnerabilities in other drivers or subsystems, developers must adhere strictly to proper resource lifecycle management practices when dealing with asynchronous timers and interrupt handlers. It is essential to use synchronization primitives like timer_shutdown_sync() rather than simpler deletion APIs whenever a driver’s callback might interact with device-specific data structures that are subject to deallocation during teardown. Additionally, implementing robust error handling paths in probe functions can prevent partial initialization states from leading to inconsistent cleanup sequences. Regular static analysis and dynamic testing tools such as KASAN (Kernel Address Sanitizer) should be employed to detect use-after-free conditions early in the development cycle. Furthermore, reviewing driver code for race conditions during state transitions is crucial, particularly when multiple execution contexts like softirqs, tasklets, or workqueues interact with shared device structures. Adhering to these practices ensures that kernel modules remain stable and secure against exploitation through timing-based attacks.