CVE-2026-80677 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()
dev_has_sync_state() reads dev->driver twice without holding device_lock() -- once for the NULL check and once to dereference ->sync_state. Some callers only hold device_links_write_lock, which doesn't prevent a concurrent unbind from clearing dev->driver via device_unbind_cleanup().
Fix it by reading dev->driver exactly once with READ_ONCE(), pairing with the WRITE_ONCE() in device_set_driver().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel vulnerability identified involves a race condition within the driver core subsystem, specifically affecting the dev_has_sync_state function. This issue arises from an improper handling of concurrent access to the device structure's driver pointer field without adequate synchronization mechanisms. The root cause lies in the fact that dev_has_sync_state performs two separate reads on the dev->driver member variable: first for a null check and subsequently to dereference the sync_state callback. These operations occur outside the protection of device_lock, which is the primary mutex intended to serialize access to critical sections involving driver binding and unbinding processes.
The operational impact stems from the fact that certain callers only acquire device_links_write_lock rather than the full device_lock. This lock provides some level of synchronization but does not prevent a concurrent thread executing device_unbind_cleanup() from clearing dev->driver through an atomic write operation. When this occurs, one execution path might observe dev->driver as non-null during its initial check while another parallel unbinding process simultaneously sets it to null via WRITE_ONCE(). This creates a classic time-of-check-to-time-of-use scenario where the subsequent dereference attempts to access memory at an address that has been invalidated or repurposed by the cleanup routine.
This race condition can lead to use-after-free scenarios, kernel panics, or undefined behavior depending on how quickly the freed memory is reallocated and what data occupies it after unbinding completes. In worst-case scenarios, this could allow local privilege escalation if an attacker can manipulate timing conditions to exploit the window between checking for nullity and dereferencing the pointer. The vulnerability highlights a common class of concurrency bugs in kernel development where developers assume that higher-level locks provide sufficient protection without considering lower-level atomic operations performed by other subsystems like device unbinding logic.
The resolution implements READ_ONCE macro usage when accessing dev->driver within dev_has_sync_state, ensuring exactly one read operation occurs atomically with respect to compiler optimizations and potential concurrent writes. This approach pairs correctly with the existing WRITE_ONCE() calls in device_set_driver(), establishing proper memory ordering guarantees across different execution contexts. By consolidating both checks into a single atomic load operation, the code eliminates the window where stale or partially updated values could be observed by competing threads.
From an industry standards perspective, this vulnerability maps to CWE-362 which describes concurrent access resulting in race conditions. The ATT&CK framework would classify such exploitation potential under T1059 command and scripting interface if leveraged for further system compromise through kernel code execution techniques. Security researchers should note that similar patterns may exist elsewhere in the driver core where device structures are accessed without proper locking granularity matching the actual synchronization requirements of each subsystem component involved.
Mitigation strategies include applying this patch to affected Linux kernels immediately, particularly those running versions prior to the fix release date. System administrators managing production environments with custom kernel builds should verify their patches align with upstream stable releases addressing driver core concurrency issues. Developers working on similar device management code paths must adopt READ_ONCE/WRITE_ONCE patterns consistently when dealing with pointers that may be modified by concurrent unbinding operations, ensuring all access points follow the same atomicity guarantees established in this fix.