GHSA-MHGR-C53R-GX3P
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-15 18:30In 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.
{
"affected": [],
"aliases": [
"CVE-2026-43327"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T14:16:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: dummy-hcd: Fix locking/synchronization error\n\nSyzbot testing was able to provoke an addressing exception and crash\nin the usb_gadget_udc_reset() routine in\ndrivers/usb/gadgets/udc/core.c, resulting from the fact that the\nroutine was called with a second (\"driver\") argument of NULL. The bad\ncaller was set_link_state() in dummy_hcd.c, and the problem arose\nbecause of a race between a USB reset and driver unbind.\n\nThese sorts of races were not supposed to be possible; commit\n7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous synchronization change\"),\nalong with a few followup commits, was written specifically to prevent\nthem. As it turns out, there are (at least) two errors remaining in\nthe code. Another patch will address the second error; this one is\nconcerned with the first.\n\nThe error responsible for the syzbot crash occurred because the\nstop_activity() routine will sometimes drop and then re-acquire the\ndum-\u003elock spinlock. A call to stop_activity() occurs in\nset_link_state() when handling an emulated USB reset, after the test\nof dum-\u003eints_enabled and before the increment of dum-\u003ecallback_usage.\nThis allowed another thread (doing a driver unbind) to sneak in and\ngrab the spinlock, and then clear dum-\u003eints_enabled and dum-\u003edriver.\nNormally this other thread would have to wait for dum-\u003ecallback_usage\nto go down to 0 before it would clear dum-\u003edriver, but in this case it\ndidn\u0027t have to wait since dum-\u003ecallback_usage had not yet been\nincremented.\n\nThe fix is to increment dum-\u003ecallback_usage _before_ calling\nstop_activity() instead of after. Then the thread doing the unbind\nwill not clear dum-\u003edriver until after the call to\nusb_gadget_udc_reset() safely returns and dum-\u003ecallback_usage has been\ndecremented again.",
"id": "GHSA-mhgr-c53r-gx3p",
"modified": "2026-05-15T18:30:30Z",
"published": "2026-05-08T15:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43327"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/218886b2ef2dea7627d3700ab0abaf4bf9d1161f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/616a63ff495df12863692ab3f9f7b84e3fa7a66d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6350c7dd33ab481ef41c931a238361490c32d15c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69ab97a693251d6a6093e630060a3c744fd58524"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/791966f85b439b261bf19865cf1c07c065ffb4b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/805b1833d6ed6da5086e610578a28e71bb54fbbb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc97fb5969177cccce2e23b31298df220fc7570d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/efbd9441f1e769a7aae1813d497cec09cbdff031"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.