https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 08:42:37 +0000 https://vulnerability.circl.lu/vuln/cve-2026-80659 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mmc: vub300: defer reset until cmd_mutex is unlocked</p> <p>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().</p> <p>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.</p> <p>This issue was found by our static analysis tool and then manually reviewed against the current tree.</p> <p>The grounded PoC kept the real worker and timeout/reset carrier:</p> <p>vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset()</p> <p>Lockdep reported the same-task recursive acquisition on cmd_mutex:</p> <p>WARNING: possible recursive locking detected ... (&amp;test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv] ... (&amp;test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv] Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv] *** DEADLOCK ***</p> <p>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…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mmc: vub300: defer reset until cmd_mutex is unlocked</p> <p>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().</p> <p>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.</p> <p>This issue was found by our static analysis tool and then manually reviewed against the current tree.</p> <p>The grounded PoC kept the real worker and timeout/reset carrier:</p> <p>vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset()</p> <p>Lockdep reported the same-task recursive acquisition on cmd_mutex:</p> <p>WARNING: possible recursive locking detected ... (&amp;test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv] ... (&amp;test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv] Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv] *** DEADLOCK ***</p> <p>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…</p> https://vulnerability.circl.lu/vuln/cve-2026-80659