{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.170-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.85-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.19.12-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003elock spinlock.  A call to stop_activity() occurs in set_link_state() when handling an emulated USB reset, after the test of dum-\u003eints_enabled and before the increment of dum-\u003ecallback_usage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum-\u003eints_enabled and dum-\u003edriver. Normally this other thread would have to wait for dum-\u003ecallback_usage to go down to 0 before it would clear dum-\u003edriver, but in this case it didn't have to wait since dum-\u003ecallback_usage had not yet been incremented.  The fix is to increment dum-\u003ecallback_usage _before_ calling stop_activity() instead of after.  Then the thread doing the unbind will not clear dum-\u003edriver until after the call to usb_gadget_udc_reset() safely returns and dum-\u003ecallback_usage has been decremented again.",
  "id": "DEBIAN-CVE-2026-43327",
  "modified": "2026-09-14T16:47:34.650711468Z",
  "published": "2026-05-08T14:16:42.243Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-43327"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-43327"
  ]
}