Description
In the Linux kernel, the following vulnerability has been resolved:

USB: dummy-hcd: Fix locking/synchronization error

Syzbot testing was able to provoke an addressing exception and crash
in the usb_gadget_udc_reset() routine in
drivers/usb/gadgets/udc/core.c, resulting from the fact that the
routine was called with a second ("driver") argument of NULL. The bad
caller was set_link_state() in dummy_hcd.c, and the problem arose
because of a race between a USB reset and driver unbind.

These sorts of races were not supposed to be possible; commit
7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"),
along with a few followup commits, was written specifically to prevent
them. As it turns out, there are (at least) two errors remaining in
the code. Another patch will address the second error; this one is
concerned with the first.

The error responsible for the syzbot crash occurred because the
stop_activity() routine will sometimes drop and then re-acquire the
dum->lock spinlock. A call to stop_activity() occurs in
set_link_state() when handling an emulated USB reset, after the test
of dum->ints_enabled and before the increment of dum->callback_usage.
This allowed another thread (doing a driver unbind) to sneak in and
grab the spinlock, and then clear dum->ints_enabled and dum->driver.
Normally this other thread would have to wait for dum->callback_usage
to go down to 0 before it would clear dum->driver, but in this case it
didn't have to wait since dum->callback_usage had not yet been
incremented.

The fix is to increment dum->callback_usage _before_ calling
stop_activity() instead of after. Then the thread doing the unbind
will not clear dum->driver until after the call to
usb_gadget_udc_reset() safely returns and dum->callback_usage has been
decremented again.
Published: 2026-05-08
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel's dummy-hcd driver contains a race condition between a USB reset and driver unbind that can cause a null pointer dereference in the usb_gadget_udc_reset routine, resulting in a kernel panic. This flaw manifests as an addressing exception that leads to a loss of availability for the affected system. The underlying weakness is a synchronization error that allows concurrent threads to manipulate shared state inconsistently, as evidenced by Syzbot testing. The crash renders the host device unresponsive until reboot, giving attackers a significant denial‑of‑service vector.

Affected Systems

All Linux kernel builds that include the dummy-hcd gadget driver and are affected by the race condition, with no explicit version bounds in the report. The vulnerability was addressed in recent commits to the kernel source seen in the referenced Git history. Systems running unpatched kernels should be considered affected.

Risk and Exploitability

The CVSS score is not provided, but the impact of a kernel panic assigns a high severity. EPSS is not available and the vulnerability is not listed in CISA KEV, so there is no known exploitation data, yet the ease of reproducing the race with a crafted USB reset suggests a moderate to high exploitation probability for a local attacker with sufficient privileges to trigger the reset or unbind. The attack vector appears to be local or possibly remote if USB interfaces can be manipulated over a networked host controller. Administrators should treat this as a high‑risk issue until a kernel update is applied.

Generated by OpenCVE AI on May 8, 2026 at 19:23 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the kernel to a version that incorporates the 7dbd8f4cabd9 patch and subsequent commits that resolve the dummy‑hcd race condition
  • If a timely kernel update is unavailable, disable the dummy‑hcd gadget driver by setting CONFIG_USB_DUMMY_HCD to n or removing the module from the system
  • Restrict USB gadget usage or apply stricter udev rules to limit which users can trigger USB resets or unbind drivers
  • Monitor kernel logs for sudden crashes or BUG messages that could indicate an attempted exploitation
  • Consider rebooting affected systems promptly after applying any of the above mitigations to ensure stability

Generated by OpenCVE AI on May 8, 2026 at 19:23 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 08 May 2026 19:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-476

Fri, 08 May 2026 14:00:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix locking/synchronization error Syzbot testing was able to provoke an addressing exception and crash in the usb_gadget_udc_reset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second ("driver") argument of NULL. The bad caller was set_link_state() in dummy_hcd.c, and the problem arose because of a race between a USB reset and driver unbind. These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first. The error responsible for the syzbot crash occurred because the stop_activity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stop_activity() occurs in set_link_state() when handling an emulated USB reset, after the test of dum->ints_enabled and before the increment of dum->callback_usage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->ints_enabled and dum->driver. Normally this other thread would have to wait for dum->callback_usage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callback_usage had not yet been incremented. The fix is to increment dum->callback_usage _before_ calling stop_activity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usb_gadget_udc_reset() safely returns and dum->callback_usage has been decremented again.
Title USB: dummy-hcd: Fix locking/synchronization error
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-05-08T13:31:12.896Z

Reserved: 2026-05-01T14:12:56.002Z

Link: CVE-2026-43327

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-05-08T14:16:42.243

Modified: 2026-05-08T14:16:42.243

Link: CVE-2026-43327

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-05-08T21:30:05Z

Weaknesses