Cloudanix VulnDB

CVE-2026-80677

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Aug 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel can let local programs interfere with device driver handling and crash the system or potentially run code with full privileges.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in dev_has_sync_state() allows concurrent device unbind to clear dev->driver between a NULL check and dereference of ->sync_state when only device_links_write_lock is held, leading to use of stale pointer or NULL dereference.

Why it matters to the business

Local users on affected Linux kernels can trigger kernel instability, crashes, or potential memory corruption that may allow privilege escalation on systems using device drivers with sync_state callbacks.

How an attack unfolds

An attacker with local access triggers repeated device bind/unbind operations while other kernel paths invoke dev_has_sync_state(), racing the window where the driver pointer is read twice without proper synchronization to obtain a usable pointer for further exploitation.

How to fix it

Update the Linux kernel to a version containing the READ_ONCE() fix in dev_has_sync_state() paired with WRITE_ONCE() in device_set_driver(). Apply vendor-supplied kernel updates as soon as available.

How to confirm the fix worked

Verify the presence of the READ_ONCE() change in drivers/base/core.c around dev_has_sync_state(); confirm no double read of dev->driver without the macro and test concurrent bind/unbind workloads under device_links_write_lock.

Typical attack path

  1. Obtain local code execution on target system
  2. Identify or create device driver instances that register sync_state callbacks
  3. Concurrently perform device unbind while triggering callers of dev_has_sync_state()
  4. Exploit resulting stale pointer or NULL dereference for memory corruption or denial of service

How to detect it

Review kernel logs for oops or panic messages referencing dev_has_sync_state, device_unbind_cleanup, or sync_state; inspect for repeated device bind/unbind activity correlated with crashes on systems running unpatched kernels.

What your security team should do

  • Prioritize kernel updates on all production Linux systems within the next maintenance window
  • Monitor upstream stable kernel releases and distribution security advisories for the backported fix
  • Restrict local unprivileged access where feasible until patches are applied
  • Include the affected driver core paths in kernel fuzzing and concurrency testing suites

The record

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

Affected packages

Ecosystem Package Introduced Fixed