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: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

A race condition exists in the Linux kernel dummy‑hcd gadget driver where a USB reset can be performed concurrently with a driver unbind. The race allows a thread to clear the driver pointer while another thread calls usb_gadget_udc_reset() with that pointer set to NULL, provoking an addressing exception. This results in a kernel panic, rendering the system unavailable. The weaknesses are a race condition (CWE‑367) and improper locking (CWE‑667).

Affected Systems

All Linux kernel builds that include the dummy‑hcd driver are potentially affected. The CPE list and vendor data highlight the 7.0 release‑candidate series (rc1 through rc7). Any kernel version that does not contain the recent commits adding the correct lock ordering is vulnerable.

Risk and Exploitability

The CVSS score of 5.5 indicates medium severity, and the EPSS score of less than 1% suggests a low likelihood of exploitation. This vulnerability is not listed in CISA KEV. The likely attack vector is local or remote USB gadget activity that can trigger a reset or unbind, which may be inferred from the nature of the race. Even though exploitation probability is low, the impact is a kernel crash that requires a reboot to recover.

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

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the kernel to a version that incorporates the 7dbd8f4cabd9 commit and follow‑up fixes for the dummy‑hcd driver
  • If a kernel update cannot be applied immediately, disable the dummy‑hcd gadget by setting CONFIG_USB_DUMMY_HCD=n or removing the module from the system
  • Restrict access to the USB gadget interface through udev rules or role‑based permissions to prevent unauthorized reset or unbind operations

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

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4606-1 linux security update
History

Tue, 19 May 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-367
References

Fri, 15 May 2026 20:45:00 +0000

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

Fri, 15 May 2026 18:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-667
CPEs cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc7:*:*:*:*:*:*
Metrics cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

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-23T16:06:42.428Z

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

Link: CVE-2026-43327

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

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

Modified: 2026-05-15T18:05:56.443

Link: CVE-2026-43327

cve-icon Redhat

Severity :

Publid Date: 2026-05-08T00:00:00Z

Links: CVE-2026-43327 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-19T01:30:26Z

Weaknesses