In the Linux kernel, the following vulnerability has been resolved: USB: dummy-hcd: Fix interrupt synchronization error This fixes an error in synchronization in the dummy-hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), which added an emulated "interrupts enabled" flag together with code emulating synchronize_irq() (it waits until all current handler callbacks have returned). But the emulated interrupt-disable occurred too late, after the driver containing the handler callback routines had been told that it was unbound and no more callbacks would occur. Commit 4a5d797a9f9c ("usb: gadget: dummy_hcd: fix gpf in gadget_setup") tried to fix this by moving the synchronize_irq() emulation code from dummy_stop() to dummy_pullup(), which runs before the unbind callback. There still were races, though, because the emulated interrupt-disable still occurred too late. It couldn't be moved to dummy_pullup(), because that routine can be called for reasons other than an impending unbind. Therefore commits 7dc0c55e9f30 ("USB: UDC core: Add udc_async_callbacks gadget op") and 04145a03db9d ("USB: UDC: Implement udc_async_callbacks in dummy-hcd") added an API allowing the UDC core to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled. That brings us to the current state of things, which is still wrong because the emulated synchronize_irq() occurs before the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur after the synchronize_irq() emulation has run, leading to the possibility that a callback handler may be running when the gadget driver is unbound. To fix this, we have to move the synchronize_irq() emulation code yet again, to the dummy_udc_async_callbacks() routine, which takes care of enabling and disabling emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are disabled, which is where it belongs.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - USB: dummy-hcd: Fix interrupt synchronization error This fixes an error in synchronization in the dummy-     hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by     commit 7dbd8f4cabd9 (USB: dummy-hcd: Fix erroneous synchronization change), which added an emulated     interrupts enabled flag together with code emulating synchronize_irq() (it waits until all current     handler callbacks have returned). But the emulated interrupt-disable occurred too late, after the driver     containing the handler callback routines had been told that it was unbound and no more callbacks would     occur. Commit 4a5d797a9f9c (usb: gadget: dummy_hcd: fix gpf in gadget_setup) tried to fix this by moving     the synchronize_irq() emulation code from dummy_stop() to dummy_pullup(), which runs before the unbind     callback. There still were races, though, because the emulated interrupt-disable still occurred too late.
    It couldn't be moved to dummy_pullup(), because that routine can be called for reasons other than an     impending unbind. Therefore commits 7dc0c55e9f30 (USB: UDC core: Add udc_async_callbacks gadget op) and     04145a03db9d (USB: UDC: Implement udc_async_callbacks in dummy-hcd) added an API allowing the UDC core     to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled. That brings us     to the current state of things, which is still wrong because the emulated synchronize_irq() occurs before     the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur     after the synchronize_irq() emulation has run, leading to the possibility that a callback handler may be     running when the gadget driver is unbound. To fix this, we have to move the synchronize_irq() emulation     code yet again, to the dummy_udc_async_callbacks() routine, which takes care of enabling and disabling     emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are     disabled, which is where it belongs. (CVE-2026-43324)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Severity
329149	SUSE SLED15: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2026:3166-1)	Nessus	SuSE Local Security Checks	medium
314407	Linux Distros Unpatched Vulnerability : CVE-2026-43324	Nessus	Misc.	high

Detections

Analytics

CVE-2026-43324

high

Tenable Plugins

medium

high