CVE-2026-80659mmc: vub300: defer reset until cmd_mutex is unlocked
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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.
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Aug 28, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | 88095e7b473a3d9ec3b9c60429576e9cbd327c89 builds before 8672b8bdbd2063b3fcbd75f729e4706fcdad2257; from 88095e7b473a3d9ec3b9c60429576e9cbd327c89 before 8344611477c9241f45f20981990780fc5f0996f8; 88095e7b473a3d9ec3b9c60429576e9cbd327c89 builds before 2e6b9a394206c76dd417c991312f349435ef35e6; 88095e7b473a3d9ec3b9c60429576e9cbd327c89 builds before 7ee7a77ec2f446109ab52cc80ace7acc22ab6211; 88095e7b473a3d9ec3b9c60429576e9cbd327c89 builds before 9f5e04235a0b59e6e30af9f45511addf2604d757; from 88095e7b473a3d9ec3b9c60429576e9cbd327c89 before bf9848a22a8e50d39d5e8d871581f0a8110f16b3; from 88095e7b473a3d9ec3b9c60429576e9cbd327c89 before c2e1d33929565fa14c48d8a5a45edc3ebfc941b2; from 88095e7b473a3d9ec3b9c60429576e9cbd327c89 before ee5fb641c4ccac8406c668d3e947eb20ce44f233 | CNA record |
References
- https://git.kernel.org/stable/c/8672b8bdbd2063b3fcbd75f729e4706fcdad2257
- https://git.kernel.org/stable/c/8344611477c9241f45f20981990780fc5f0996f8
- https://git.kernel.org/stable/c/2e6b9a394206c76dd417c991312f349435ef35e6
- https://git.kernel.org/stable/c/7ee7a77ec2f446109ab52cc80ace7acc22ab6211
- https://git.kernel.org/stable/c/9f5e04235a0b59e6e30af9f45511addf2604d757
- https://git.kernel.org/stable/c/bf9848a22a8e50d39d5e8d871581f0a8110f16b3
- https://git.kernel.org/stable/c/c2e1d33929565fa14c48d8a5a45edc3ebfc941b2
- https://git.kernel.org/stable/c/ee5fb641c4ccac8406c668d3e947eb20ce44f233
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.