{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-43324",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-43324"
  ],
  "published": "2026-05-08T13:31:29Z",
  "summary": "USB: dummy-hcd: Fix interrupt synchronization error",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: dummy-hcd: Fix interrupt synchronization error\n\nThis fixes an error in synchronization in the dummy-hcd driver.  The\nerror has a somewhat involved history.  The synchronization mechanism\nwas introduced by commit 7dbd8f4cabd9 (\"USB: dummy-hcd: Fix erroneous\nsynchronization change\"), which added an emulated \"interrupts enabled\"\nflag together with code emulating synchronize_irq() (it waits until\nall current handler callbacks have returned).\n\nBut the emulated interrupt-disable occurred too late, after the driver\ncontaining the handler callback routines had been told that it was\nunbound and no more callbacks would occur.  Commit 4a5d797a9f9c (\"usb:\ngadget: dummy_hcd: fix gpf in gadget_setup\") tried to fix this by\nmoving the synchronize_irq() emulation code from dummy_stop() to\ndummy_pullup(), which runs before the unbind callback.\n\nThere still were races, though, because the emulated interrupt-disable\nstill occurred too late.  It couldn't be moved to dummy_pullup(),\nbecause that routine can be called for reasons other than an impending\nunbind.  Therefore commits 7dc0c55e9f30 (\"USB: UDC core: Add\nudc_async_callbacks gadget op\") and 04145a03db9d (\"USB: UDC: Implement\nudc_async_callbacks in dummy-hcd\") added an API allowing the UDC core\nto tell dummy-hcd exactly when emulated interrupts and their callbacks\nshould be disabled.\n\nThat brings us to the current state of things, which is still wrong\nbecause the emulated synchronize_irq() occurs before the emulated\ninterrupt-disable!  That's no good, beause it means that more emulated\ninterrupts can occur after the synchronize_irq() emulation has run,\nleading to the possibility that a callback handler may be running when\nthe gadget driver is unbound.\n\nTo fix this, we have to move the synchronize_irq() emulation code yet\nagain, to the dummy_udc_async_callbacks() routine, which takes care of\nenabling and disabling emulated interrupt requests.  The\nsynchronization will now run immediately after emulated interrupts are\ndisabled, which is where it belongs.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.47-1+rpt4"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-2712",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v6",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v8",
            "binary_version": "1:6.1.47-1+rpt4"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.47-1+rpt4": {
            "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e",
            "upstream_version": "6.1.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.1.168",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-43324"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/d847f375b1bcea713143bc02720d13d2d01b012a"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/cbf7df5e5d27cd5bea92ee9a75a4b28dbcc718d4"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/5aa776c8615bea3b1eaeec87b0788375800ead4f"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/94d4fab1dd9e64f45449bcc7d6a5acf796b13015"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/5687a09776069bd915560021c9728ca528440128"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/8bcd80219d8e10e660bf29b20e41bb8beb4e4cb7"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/2ca9e46f8f1f5a297eb0ac83f79d35d5b3a02541"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T13:16:28Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The vulnerable dummy-hcd path is reached through local USB gadget/host emulator interfaces such as raw-gadget, usbfs, configfs, or sysfs unbind paths. It is not network-reachable and dummy-hcd is an in-kernel emulator rather than a physically attached USB device.\nAC:L - Although this is a race, a local attacker can drive both sides by generating emulated USB activity while triggering gadget driver unbind, and the race can be retried. There are no special external conditions beyond attacker-controlled timing.\nPR:L - Exploitation requires local access to the configured dummy-hcd/gadget userspace interfaces, but the relevant raw-gadget and usbfs paths do not themselves impose a kernel capability check once accessible. When uncertain between root-only setup and normal local device access, the higher-severity PR:L is appropriate.\nUI:N - No victim action is needed after the attacker has local access to the relevant device interfaces. The attacker can trigger emulated USB callbacks and unbind locally.\nS:U - The impact remains within the same kernel security authority. This is a standard local kernel memory-safety/availability issue, not a VM escape or cross-authority boundary violation.\nC:H - The synchronization bug can allow asynchronous gadget callbacks to run after or during gadget driver unbind, leaving callback code operating on stale or cleared gadget-driver state. This is a use-after-unbind/use-after-free class condition, so kernel memory disclosure is a defensible worst-case impact.\nI:H - Callback execution against freed or invalid gadget-driver state can be leveraged as kernel memory corruption rather than merely a clean failure. Under the required higher-severity rule, a UAF-style kernel race supports potential arbitrary write or code execution.\nA:H - At minimum, the race can crash the kernel through NULL dereference or stale pointer use in gadget callbacks, as related dummy-hcd synchronization bugs have done. Kernel oops/panic is high availability impact."
    }
  }
}