CVE-2026-31688

What it actually does

CVE-2026-31688 is a Linux kernel driver core use-after-free race condition involving driver_match_device() and bus match() callbacks. Some code paths, specifically bind_store() and __driver_attach(), invoked device/driver matching without holding device_lock(dev), while other paths did hold the lock. The driver_override field depends on that lock for safe lifetime and concurrency handling; without it, concurrent modification or release can cause the kernel to access freed memory. A local authenticated attacker able to interact with driver binding or device-driver matching paths could potentially trigger memory corruption in kernel context, leading to local privilege escalation, kernel crash, or arbitrary code execution depending on exploitability on the target kernel and hardware/driver configuration.

Why it matters to the business

Successful exploitation could allow a local user or compromised low-privilege process to gain kernel-level privileges or crash affected Linux systems. The most important operational risks are privilege escalation after initial compromise, bypass of host isolation assumptions, and unplanned outages due to kernel panic. This is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has no public exploit maturity reported, which lowers immediate internet-scale urgency; however, because the flaw is in the Linux kernel and can affect many downstream distributions and appliances, organizations should treat it as a significant local privilege-escalation and stability issue, especially on multi-user systems, shared compute, developer workstations, containers sharing a vulnerable host kernel, and environments where untrusted users can execute local code.

How an attack unfolds

An attacker first needs local code execution or an authenticated foothold on a vulnerable Linux system. They then exercise sysfs or driver-core paths that cause bind_store() or __driver_attach() to perform driver/device matching while racing concurrent changes to driver_override or related device state. Because the vulnerable paths do not consistently hold device_lock(dev), the match callback can observe or dereference memory after it has been freed. With sufficient timing control and kernel heap manipulation, the attacker may convert the use-after-free into controlled kernel memory corruption. The likely outcomes are a denial-of-service kernel crash or, in a more advanced exploit, execution of attacker-controlled code in kernel context and escalation to root. Exploitation is local and requires privileges sufficient to reach the vulnerable driver binding or attachment interfaces, but it does not require user interaction.

How to fix it

Upgrade the Linux kernel to a vendor release that contains the upstream fix enforcing device_lock(dev) for driver_match_device() through the locked helper path. Because fixed versions are distribution-specific and no exact fixed package versions were provided, use your Linux distribution’s security advisory and kernel package changelog for CVE-2026-31688, then install the corrected kernel and reboot into it. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting users permitted to write to driver bind/unbind or driver_override sysfs interfaces, enforcing least privilege for service accounts, disabling unnecessary hotplug/driver-management workflows, and using mandatory access control policies such as SELinux or AppArmor to limit access to sensitive sysfs driver-management paths. Container updates alone are not sufficient if containers share a vulnerable host kernel; the host kernel must be updated and rebooted.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated. On Linux systems, compare uname -r with the distribution’s fixed kernel advisory, verify the relevant kernel package version through the system package manager, and ensure the host has rebooted after installation. For source-based or custom kernels, verify the driver core change introducing driver_match_device_locked() and enforcing the device_lock assertion around driver_match_device() is present. If feasible in test environments, run kernel concurrency or driver binding stress tests with CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP enabled and confirm there are no use-after-free reports, KASAN findings, lockdep warnings, or kernel oops events associated with driver_override, bind_store(), __driver_attach(), or driver_match_device(). Also audit permissions on /sys/bus/*/drivers/*/bind, /sys/bus/*/drivers/*/unbind, and device driver_override files to confirm only intended privileged users or services can write to them.

Typical attack path

1. Obtain local access to a vulnerable Linux host as a low-privilege user or via a previously compromised service account.
2. Identify available device-driver binding or attachment interfaces and buses that use driver_override.
3. Trigger repeated driver binding, unbinding, probing, or attachment operations that invoke bind_store() or __driver_attach().
4. Race those operations against concurrent modification or release of driver_override-backed device state.
5. Cause driver_match_device() or bus match() callbacks to dereference freed memory.
6. Use kernel heap shaping to turn the use-after-free into a kernel crash or controlled memory corruption.
7. Escalate privileges to root or disrupt system availability through a kernel panic.

How to detect it

Look for evidence of attempted local exploitation and resulting kernel instability rather than remote network indicators. Relevant sources include kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, auditd records, EDR telemetry, and shell/process accounting if available. Investigate kernel oops, panic, general protection fault, KASAN, slab, or use-after-free reports mentioning driver_override, driver_match_device, bind_store, __driver_attach, bus match callbacks, or sysfs driver binding. Use auditd or equivalent telemetry to detect writes to /sys/bus/*/drivers/*/bind, /sys/bus/*/drivers/*/unbind, and /sys/bus/*/devices/*/driver_override, especially high-frequency writes, writes by non-administrative users, or activity preceding a kernel crash. Because there are no known public exploit campaigns or named threat actors for this CVE at this time, detection should focus on abnormal local driver-management behavior, kernel memory-corruption artifacts, and privilege-escalation follow-on activity such as unexpected root shells, new privileged users, modified sudoers files, or suspicious setuid binaries created shortly after driver-core errors.

• driver_override
• driver_match_device
• driver_match_device_locked
• bind_store
• __driver_attach
• use-after-free
• BUG: KASAN: use-after-free
• slab-use-after-free
• general protection fault
• kernel NULL pointer dereference
• kernel panic
• Oops:
• /sys/bus/*/drivers/*/bind
• /sys/bus/*/drivers/*/unbind
• /sys/bus/*/devices/*/driver_override

What your security team should do

• Prioritize patching multi-user Linux servers, shared compute nodes, virtualization/container hosts, CI/CD runners, developer workstations, and systems where untrusted users or workloads can execute local code.
• Track and deploy the fixed kernel from each Linux distribution or appliance vendor, then reboot systems to ensure the fixed kernel is active.
• Inventory systems exposing writable sysfs driver binding or driver_override interfaces and restrict access to trusted administrators only.
• Harden local privilege boundaries with SELinux, AppArmor, seccomp, sudo restrictions, and least-privilege service account controls.
• Monitor for kernel crashes, KASAN or slab use-after-free messages, lockdep warnings, and unusual writes to driver bind/unbind or driver_override sysfs paths.
• Treat suspicious local exploitation attempts as post-compromise activity: investigate the initial access vector, credential use, persistence, and lateral movement in addition to the kernel vulnerability itself.
• For container platforms, patch and reboot the host kernel; rebuilding application containers does not remediate a host-kernel vulnerability.