CVE-2026-80659: Linux Kernel Race Condition Vulnerability

CVE-2026-80659 Overview

CVE-2026-80659 is a recursive locking flaw in the Linux kernel's vub300 MMC (MultiMediaCard) USB host driver. The vub300_cmndwork_thread() worker holds cmd_mutex while sending a command and waiting for its response. When the response times out, __vub300_command_response() synchronously resets the USB device via usb_reset_device(), which re-enters the driver through vub300_pre_reset() and attempts to acquire the same cmd_mutex. Lockdep flagged the same-task recursive acquisition as a potential deadlock. The upstream fix defers the reset until after the worker clears in-flight command state and drops cmd_mutex.

Critical Impact
A response timeout on a vub300 SDIO/SD host device can trigger a kernel deadlock, freezing the MMC worker thread and blocking further command processing on the affected device.

Affected Products

Linux kernel — drivers/mmc/host/vub300.c (VUB300 SDIO/SD host driver)
Stable kernel branches receiving backports referenced by commits 2e6b9a3, 7ee7a77, 8344611, 8672b8b, 9f5e042, bf9848a, c2e1d33, and ee5fb64
Systems using the Elan VUB300 USB-to-SDIO/SD adapter

Discovery Timeline

2026-08-28 - CVE-2026-80659 published to NVD
2026-08-28 - Last updated in NVD database

Technical Details for CVE-2026-80659

Vulnerability Analysis

The defect is a classic same-thread recursive mutex acquisition [Deadlock]. The vub300_cmndwork_thread() worker acquires cmd_mutex, then submits a command URB and waits for the response. If the wait times out, __vub300_command_response() cancels the URBs and calls usb_lock_device_for_reset() followed by usb_reset_device(). The USB core invokes the driver's pre-reset callback, vub300_pre_reset(), which itself attempts to take cmd_mutex. Because the worker thread still owns the lock from the command path, the second acquisition attempt deadlocks the worker.

Lockdep produced the diagnostic "possible recursive locking detected" against &test_vub300.cmd_mutex, with the call chain traversing vub300_cmndwork_thread → __vub300_command_response → usb_reset_device → vub300_pre_reset. The vulnerability was identified by a static analysis tool and manually confirmed against the current tree.

Root Cause

The root cause is a lock ordering violation between the command path and the USB reset path. Both paths require cmd_mutex, but the command path holds it across a synchronous USB reset that re-enters the driver. Nothing releases the mutex before the reset callback runs, producing the recursive acquisition condition.

Attack Vector

This flaw is a local reliability and availability issue that surfaces on hosts using VUB300 hardware. Any condition that produces a command response timeout — a hung or misbehaving SDIO/SD card, a wedged bus, or a malicious or malfunctioning USB device presented to the host — will trigger the reset path and the deadlock. Triggering the flaw does not require attacker-controlled code paths in the kernel; a physical or virtualized USB device that fails to respond in time is sufficient to hang the MMC worker.

No verified public exploit code is available for this issue. The reproduction described in the advisory relies on the natural timeout/reset carrier documented in the changelog.

Detection Methods for CVE-2026-80659

Indicators of Compromise

Kernel log entries containing WARNING: possible recursive locking detected referencing cmd_mutex in the vub300 module.
Hung task warnings naming vub300_cmndwork_thread or the vub300_cmd_wq workqueue.
MMC command timeouts followed by USB device reset attempts on the VUB300 adapter that never complete.

Detection Strategies

Enable CONFIG_PROVE_LOCKING and CONFIG_DEBUG_LOCKDEP in test and staging kernels to surface recursive acquisition warnings before they reach production.
Monitor dmesg and journald for hung_task warnings tied to vub300_cmndwork_thread and correlate with USB reset events on VUB300 vendor and product IDs.
Track running kernel versions against the fixed commits listed in the upstream stable tree to identify unpatched hosts.

Monitoring Recommendations

Forward kernel logs to a centralized logging or SIEM platform and alert on vub300, cmd_mutex, and hung_task string matches.
Instrument MMC and USB subsystem metrics (command timeouts, reset counts) to detect anomalous timeout rates that could precede the deadlock.
Include VUB300-equipped hosts in periodic patch-compliance scans against the referenced kernel.org stable commits.

How to Mitigate CVE-2026-80659

Immediate Actions Required

Upgrade to a Linux kernel that contains the upstream fix, referenced by commits 2e6b9a3, 7ee7a77, 8344611, 8672b8b, 9f5e042, bf9848a, c2e1d33, and ee5fb64.
Audit inventory for hosts using the VUB300 USB SDIO/SD adapter and prioritize them for patching.
Reboot affected systems after applying the kernel update to load the fixed driver.

Patch Information

The upstream fix modifies __vub300_command_response() to return a flag when the timeout path requires a device reset. The reset is deferred until after vub300_cmndwork_thread() has cleared the in-flight command state and dropped cmd_mutex. The reset is still issued before mmc_request_done(), preserving request completion ordering while eliminating the recursive lock. Patches have been backported across multiple stable branches; consult your distribution's kernel advisories for the exact package version containing the fix.

Workarounds

If patching cannot be scheduled immediately, unload the vub300 module (modprobe -r vub300) on hosts that do not require the adapter.
Blacklist the vub300 driver on systems where the VUB300 hardware is not in use to prevent the vulnerable code path from loading.
Physically disconnect or disable the VUB300 USB adapter on systems where MMC/SDIO functionality is not required.

bash

# Prevent the vulnerable driver from loading until the kernel is patched
echo "blacklist vub300" | sudo tee /etc/modprobe.d/blacklist-vub300.conf
sudo modprobe -r vub300 2>/dev/null || true
sudo update-initramfs -u