CVE-2026-90029 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: realtek_cr: fix use-after-free on disconnect
realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free.
Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed.
Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor.
Found by static analysis.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the Linux kernel's USB storage driver for Realtek card readers represents a critical use-after-free condition that arises from improper synchronization between resource deallocation and active hardware timers. This flaw is located within the realtek_cr_destructor function, which serves as the cleanup routine when the device is disconnected or fails to initialize correctly. The core technical issue stems from the sequence of operations performed during this teardown process. Specifically, the original implementation invoked timer_delete() on a kernel timer structure before ensuring that any associated callback functions had completed their execution and were no longer capable of rearming themselves. In Linux kernel programming, timers are asynchronous mechanisms; once armed, they can trigger at any time based on system tick counts or hardware events. If the memory containing the timer object is freed while the interrupt context for the timer callback is still executing or if the callback logic includes code to restart itself, the subsequent access to that now-freed memory results in undefined behavior. This typically manifests as a use-after-free vulnerability, which can lead to kernel panics, data corruption, or potentially be exploited by local attackers with physical access to trigger device disconnects rapidly to cause denial of service conditions.
The operational impact of this flaw is significant for system stability and security integrity. Because the timer callback may rearm itself before the destructor completes its cleanup sequence, the driver attempts to interact with memory that has already been returned to the kernel's allocator pool. This race condition creates a window where stale pointers are dereferenced against potentially reallocated data structures belonging to other subsystems or processes. From an attacker perspective, while this is primarily a stability issue leading to system crashes (denial of service), sophisticated exploitation could theoretically leverage the use-after-free state to achieve arbitrary code execution if specific memory layout conditions align with kernel exploit primitives such as heap spraying techniques. The vulnerability was discovered through static analysis tools designed to detect race conditions and improper resource management patterns in low-level driver code, highlighting the importance of automated verification in maintaining robust kernel security postures.
To mitigate this vulnerability, the fix implements a rigorous synchronization strategy using timer_shutdown_sync(). Unlike simple deletion functions that may return before pending callbacks finish, timer_shutdown_sync() ensures that all currently running instances of the timer callback have completed their execution and prevents any further rearming of the timer. This function effectively blocks until the asynchronous operations associated with the timer are fully terminated, thereby guaranteeing that no code path can access the timer structure after it has been logically removed from active service. Furthermore, the remediation involves restructuring the initialization logic by moving the timer_setup() call into the init_realtek_cr() function. This change ensures that the timer is properly initialized before any error handling paths are invoked during device setup. By establishing this correct lifecycle order, the driver avoids scenarios where a failure path might trigger the destructor on an uninitialized or partially configured timer object, which could otherwise lead to similar race conditions or null pointer dereferences if not handled correctly.
From a classification perspective, this vulnerability aligns with CWE-416: Use After Free, as it involves accessing memory after it has been freed due to improper synchronization of resource lifecycles. Additionally, the attack vector relates to physical interaction with hardware devices, which can be mapped to ATT&CK technique T1539: Steal Web Session Cookie if we consider broader implications, but more accurately fits within local privilege escalation or denial of service vectors enabled by physical access (T1078 Valid Accounts or similar physical intrusion scenarios). The fix exemplifies best practices in kernel driver development, emphasizing the necessity of using synchronous shutdown mechanisms for hardware timers and ensuring strict ordering between resource initialization and cleanup routines. Developers must remain vigilant about asynchronous callback lifecycles when managing hardware resources to prevent race conditions that compromise system stability and security.