Description

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().

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-28T08:16:52.983Z",
  "pubdate": "2026-08-28T08:16:52.983Z",
  "executiveSummary": "A race condition vulnerability has been identified within the Linux kernel's driver core component, specifically affecting the dev_has_sync_state() function.\nThe vulnerability stems from an improper synchronization mechanism when accessing the dev->driver pointer, which can be modified concurrently by other kernel threads during an unbind operation.\nThis flaw can lead to a NULL pointer dereference or the usage of stale data, potentially resulting in a kernel panic or a denial-of-service (DoS) condition.\nThe issue affects systems where device driver management operations, such as concurrent unbinds, occur without the protection of the device_lock().\nAn attacker capable of triggering concurrent driver unbind processes may be able to destabilize the kernel, leading to system crashes.\nThere are no specific authentication requirements for exploitation, as the condition is triggered through standard driver management workflows.",
  "technicalDetails": "The vulnerability resides in the driver core management logic, specifically within the function dev_has_sync_state(). During routine execution, the kernel performs two separate reads of the dev->driver pointer. The first read is conducted to verify if the pointer is NULL, and the second read occurs later to dereference the ->sync_state callback.\nIn the original implementation, these operations were not atomic, and the code did not hold the device_lock() during these reads. While some callers utilize the device_links_write_lock, this lock is insufficient to prevent a concurrent unbind operation from executing device_unbind_cleanup().\nDuring the period between the first read and the second read, an asynchronous kernel thread could invoke device_unbind_cleanup(), which clears the dev->driver field via a WRITE_ONCE() operation. Because the initial check for NULL in dev_has_sync_state() may pass, the subsequent dereference of the now-stale or NULL pointer triggers a memory access violation.\nThe exploitation flow involves a race condition where the attacker triggers a driver unbind operation exactly during the interval between the two reads performed by dev_has_sync_state(). If the timing is precise, the kernel attempts to access the sync_state member of a driver structure that has already been cleared or freed, leading to a kernel-level exception.\nThis vulnerability is classified as a data race leading to a null pointer dereference. The root cause is the lack of memory atomicity when accessing a shared kernel structure that is mutable during the driver lifecycle. By ensuring the pointer is captured exactly once using READ_ONCE(), the kernel enforces a single, stable view of the driver state for the duration of the function call, thereby preventing the race window and ensuring consistency with the corresponding WRITE_ONCE() in device_set_driver()."
}