CVE-2026-80677: driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()
In the Linux kernel, the following vulnerability has been resolved:
driver core: use READONCE() for dev->driver in devhassyncstate()
devhassyncstate() reads dev->driver twice without holding devicelock() -- once for the NULL check and once to dereference ->syncstate. Some callers only hold devicelinkswritelock, which doesn't prevent a concurrent unbind from clearing dev->driver via deviceunbindcleanup().
Fix it by reading dev->driver exactly once with READONCE(), pairing with the WRITEONCE() in devicesetdriver().
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify dev_has_sync_state() to read dev->driver exactly once using READ_ONCE(), and ensure this is paired with the WRITE_ONCE() used in device_set_driver() so concurrent unbind cannot clear dev->driver between the NULL check and dereference.
Linux kernel (device core / driver core) dev->driver access in dev_has_sync_state() uses READ_ONCE() = Use READ_ONCE() for dev->driver in dev_has_sync_state() instead of reading dev->driver twice
Event History
Frequently Asked Questions
What conditions are required for this issue to occur?
A call to dev_has_sync_state() must race with a concurrent driver unbind that clears dev->driver. The vulnerable path reads the driver pointer once to test for NULL and again to access sync_state without holding device_lock().
Does holding device_links_write_lock prevent the race?
No. Some affected callers hold device_links_write_lock, but that lock does not prevent device_unbind_cleanup() from clearing dev->driver concurrently.
What change addresses the issue?
The fix reads dev->driver once with READ_ONCE() before checking or dereferencing it. This is paired with the existing WRITE_ONCE() in device_set_driver().