Description
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.
Published: 2026-08-28
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vub300 driver holds a mutex while sending a USB command and waits for a response. If the command times out, the driver attempts to reset the USB device synchronously, re‑entering the driver and trying to acquire the same mutex again. This results in a recursive lock that deadlocks the task, preventing the driver from releasing the mutex and completing further operations. The device becomes unresponsive, and any processes relying on the driver can be blocked, effectively denying service to that component.

Affected Systems

All Linux kernel installations that include the vub300 driver are potentially affected. No specific kernel release or version range is listed, so any kernel that contains the vub300 driver code without the fix is vulnerable.

Risk and Exploitability

The CVSS score is not disclosed. EPSS is not available, and the vulnerability is not in CISA’s KEV catalog, suggesting no known widespread exploitation yet. The likely attack vector is local or remote via USB traffic: an attacker who can influence USB command flow on the host could trigger the timeout condition and induce the deadlock. The impact is a denial of service to the affected USB interface, with a severity that could be considered medium to high depending on the device’s role in the system.

Generated by OpenCVE AI on August 28, 2026 at 11:54 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel or apply the vendor patch that defers the USB reset until cmd_mutex is released before calling usb_reset_device()
  • After applying the fix, reboot the system or reload the affected module so the new code path is active
  • If the device remains unresponsive after the patch, disable or unload the vub300 module to prevent further deadlocks

Generated by OpenCVE AI on August 28, 2026 at 11:54 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 28 Aug 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Fri, 28 Aug 2026 07:30:00 +0000

Type Values Removed Values Added
Description 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.
Title mmc: vub300: defer reset until cmd_mutex is unlocked
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-28T06:49:04.389Z

Reserved: 2026-08-26T14:34:25.780Z

Link: CVE-2026-80659

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-28T08:16:51.020

Modified: 2026-08-28T08:16:51.020

Link: CVE-2026-80659

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-28T12:00:10Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')