Look up another CVE · open CVE-2026-80677 in the interactive tracker
CVE-2026-80677
driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()
Published 2026-08-28 (2 months ago) by the Linux kernel CNA. Subsystem include/linux. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-80677 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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().
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
include/linux/device.h
- What this is
- DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFSMAINTAINERS section matched on include/linux/device.h · driver-core@lists.linux.dev · Supported
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-08-28 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- include/linux
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.6 | 5.10.261 | 89789e4c1419 |
| 5.6 | 5.15.212 | 51b3e1de53ee |
| 5.6 | 6.1.178 | 358697929351 |
| 5.6 | 6.6.145 | 5e79e0180515 |
| 5.6 | 6.12.97 | 860885fcd261 |
| 5.6 | 6.18.40 | cc77f0d91e32 |
| 5.6 | 7.1.5 | 9b0f4082a097 |
| 5.6 | 7.2 | e9506871a8ea |
| 5.5.13 | 0 | 0 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The flaw is in the driver-core device-link sync_state path, reached only via local device lifecycle operations (probe/bind, sysfs unbind, USBDEVFS disconnect/connect, module unload); there is no network, Bluetooth, or remote protocol entry point into dev_has_sync_state().
- AC:LAttack complexity, low
- An attacker controls both race sides: one thread drives device_links_driver_bound() through USB connect/probe or bind while another hammers USBDEVFS_DISCONNECT or sysfs unbind on the same or linked supplier device, retriable at high frequency with no outcome depending on uncontrollable victim state.
- PR:LPrivileges required, low
- USBDEVFS_DISCONNECT and USBDEVFS_CONNECT on /dev/bus/usb require no capability checks—only rw access to the usbfs node that udev uaccess rules routinely grant seat users—so unprivileged local users can drive the supplier unbind concurrent with automatic probe/link updates without init-namespace root.
- UI:NUser interaction, none
- The attacker initiates both the probe/device-link update and the concurrent unbind from their own processes; USB hotplug and automatic driver binding on shared workstations or kiosks also exercise this path without any deliberate action by another user.
- S:UScope, unchanged
- The TOCTOU and any resulting kernel memory fault or corruption stay within the host kernel driver-core security authority; exploitation does not cross VM, IOMMU, or sandbox boundaries.
- C:HConfidentiality impact, high
- Between the two unsynchronized dev->driver loads, concurrent device_unbind_cleanup() can clear the pointer (NULL dereference of ->sync_state) or leave a stale device_driver pointer whose sync_state field is read from freed module memory—a use-after-free read per kernel CNA UAF guidance.
- I:HIntegrity impact, high
- Use-after-free and torn pointer reads of dev->driver grant attacker-influenced heap reuse over the device_driver object; per CNA guidance UAF races enable corruption primitives and the freed sync_state function-pointer field can steer subsequent sync_state() dispatch on linked devices.
- A:HAvailability impact, high
- Reloading dev->driver as NULL between the two reads makes dev->driver->sync_state a NULL-page dereference, and the stale-pointer or post-rmmod variant faults on unmapped memory—either way a repeatable kernel oops/panic in driver-core device-link processing.