CVE-2026-80659

None

CVSS

—

EPSS

0.2%

Published

Aug 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A locking mistake in a USB card reader driver can freeze the system when commands take too long, requiring a reboot to recover.

Exploitation: Local Privilege
Attacker needs: Local User
Complexity: Moderate
Impact: Denial Of Service
Component: OS kernel
Class: Race Condition
Remediation: Patch
Effort: Low
Patch risk: Low

What it actually does

Deadlock from recursive acquisition of cmd_mutex when a command timeout triggers usb_reset_device() from within the locked vub300_cmndwork_thread() path, re-entering via vub300_pre_reset().

Why it matters to the business

Systems using vub300 USB SDIO adapters may experience kernel deadlocks or hangs during USB command timeouts, leading to loss of SD card functionality and potential system instability until reboot.

How an attack unfolds

An attacker with local access or the ability to induce command timeouts on a vub300 device can trigger the timeout path in __vub300_command_response(), causing the worker thread to attempt recursive mutex acquisition during the reset, resulting in deadlock.

How to fix it

Update the Linux kernel to a version containing the fix that returns a reset flag from __vub300_command_response() and performs the reset after dropping cmd_mutex; rebuild and deploy the updated kernel on affected systems.

How to confirm the fix worked

Confirm the presence of the patched code path that defers usb_reset_device() until after cmd_mutex is released; test command timeout scenarios to verify no recursive lock warnings occur in lockdep.

Typical attack path

Attach or interact with a vub300 USB device to queue MMC commands
Force a command response timeout in vub300_cmndwork_thread()
Trigger __vub300_command_response() timeout handling that calls usb_reset_device()
vub300_pre_reset() attempts to acquire the still-held cmd_mutex, causing deadlock

How to detect it

Inspect kernel logs for lockdep warnings mentioning cmd_mutex and vub300_cmndwork_thread; look for USB reset attempts during MMC command processing in dmesg or ftrace output.

What your security team should do

Prioritize kernel updates for any systems exposing vub300 drivers in production
Monitor kernel logs for lockdep recursive locking warnings related to cmd_mutex
Disable or avoid vub300 devices in high-availability environments until patched

The record

In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: defer reset until cmd_mutex is unlocked vub300_cmndwork_thread() holds cmd_mutex while it sends a command and waits for the command response. If the response wait times out, __vub300_command_response() kills the command URBs and then synchronously resets the USB device through usb_reset_device(). That reset path re-enters the driver through vub300_pre_reset(), which also takes cmd_mutex. The worker therefore tries to acquire the same mutex recursively while it is still holding it from the command path. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real worker and timeout/reset carrier: vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset() Lockdep reported the same-task recursive acquisition on cmd_mutex: WARNING: possible recursive locking detected ... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv] ... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv] Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv] *** DEADLOCK *** Return a flag from __vub300_command_response() when the timeout path needs a device reset, then perform the reset after vub300_cmndwork_thread() has cleared the in-flight command state and dropped cmd_mutex. The reset is still attempted before mmc_request_done(), preserving the existing request completion ordering while avoiding the recursive lock.

Affected packages

Ecosystem	Package	Introduced	Fixed