CVE-2026-43324

What it actually does

This is a local Linux kernel race condition in the USB dummy host controller driver, dummy-hcd. The flaw occurs during USB gadget driver unbind and interrupt-callback synchronization: emulated interrupt callbacks can continue after the kernel believes they have been quiesced, allowing a callback handler to run while the gadget driver is being unbound. In practical terms, this can create a use-after-free or invalid callback execution window in kernel context. A local user who can interact with the dummy-hcd USB gadget/emulation path may be able to trigger kernel memory corruption, causing denial of service and potentially escalating privileges to kernel-level code execution. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could allow a local attacker to crash affected Linux systems or potentially gain elevated privileges, which may lead to full host compromise. The most exposed systems are likely development, testing, CI, virtualization, USB gadget testing, or embedded environments where the dummy-hcd module is available or actively used. Because this is not listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, broad internet-scale exploitation is unlikely; however, the operational impact can still be severe on multi-user Linux systems or build/test infrastructure where untrusted users or workloads can access kernel USB gadget functionality.

How an attack unfolds

An attacker first obtains local, low-privileged access to a Linux system where the dummy-hcd driver is present and loadable or already loaded. They then exercise the USB gadget emulation path, typically by causing gadget drivers to bind and unbind while dummy-hcd is processing emulated interrupt callbacks. By repeatedly racing gadget teardown with callback execution, the attacker attempts to hit the window where the kernel has performed interrupt synchronization before interrupts are actually disabled. If successful, an emulated callback can execute after the gadget driver has begun unbinding, potentially referencing stale state or freed memory. The most reliable outcome is a kernel crash or hang; with additional exploit engineering, the race may be shaped into kernel memory corruption that permits local privilege escalation.

How to fix it

Apply a Linux kernel update that includes the upstream fix moving the synchronize_irq() emulation into dummy_udc_async_callbacks() immediately after emulated interrupts are disabled. No exact fixed package versions were provided, so use vendor advisories for the relevant distribution or kernel build to identify the corrected kernel release. Where immediate patching is not possible, reduce exposure by preventing use of the dummy-hcd module on systems that do not require USB gadget emulation. Consider blacklisting dummy_hcd, removing it from custom kernels, restricting module loading, and limiting access to USB gadget/configfs interfaces to trusted administrators only. Reboot after kernel updates or module changes to ensure the vulnerable code is no longer active.

How to confirm the fix worked

Confirm the running kernel version matches a vendor release containing the fix, not just that an updated package is installed. Verify whether dummy_hcd is loaded with tools such as lsmod or by checking /sys/module/dummy_hcd. Confirm that unneeded dummy-hcd usage has been disabled by attempting to load the module only in a controlled test environment and verifying that policy blocks it where intended. For source-based or custom kernels, confirm the patched dummy-hcd code performs interrupt disable before synchronization in the async callback control path. After remediation, review kernel logs during USB gadget bind/unbind testing to ensure no dummy-hcd related warnings, general protection faults, use-after-free reports, lockdep splats, or kernel oops events occur.

Typical attack path

1. Gain local access to an affected Linux system with low privileges.
2. Determine whether the dummy-hcd kernel module is available, loaded, or can be loaded.
3. Interact with USB gadget/emulation interfaces, commonly through gadget configuration and bind/unbind operations.
4. Repeatedly trigger gadget teardown while emulated interrupt callbacks are active.
5. Win the synchronization race so a callback executes after the gadget driver is considered unbound.
6. Cause kernel memory corruption, leading to denial of service or potential privilege escalation.

How to detect it

To determine whether exploitation may already have occurred, review kernel and system logs for evidence of dummy-hcd activity followed by kernel faults, hangs, or privilege anomalies. Useful sources include journald, /var/log/kern.log, /var/log/messages, audit logs, module-load telemetry, EDR process/module events, and crash dump systems such as kdump, apport, ABRT, or vmcore repositories. Look for unexpected loading of dummy_hcd, repeated USB gadget bind/unbind operations, kernel oops or panic messages in dummy-hcd functions, general protection faults, use-after-free reports from KASAN, lockdep warnings, or stack traces mentioning dummy_udc_async_callbacks, dummy_pullup, dummy_stop, gadget_setup, or related USB gadget code. Correlate these events with local user sessions, CI jobs, container workloads, modprobe activity, writes to USB gadget/configfs paths, and any subsequent privilege escalation indicators such as unexpected root shells, new setuid binaries, suspicious kernel module loads, or abnormal changes to authentication logs. Because this is a race condition and no public exploit indicators were provided, detection should focus on behavioral evidence rather than a single network signature.

• dummy_hcd
• dummy-hcd
• modprobe dummy_hcd
• insmod dummy_hcd
• /sys/module/dummy_hcd
• /sys/kernel/config/usb_gadget
• dummy_udc_async_callbacks
• dummy_pullup
• dummy_stop
• gadget_setup
• USB: dummy-hcd
• usb: gadget: dummy_hcd
• general protection fault
• kernel BUG
• kernel panic
• BUG: KASAN: use-after-free
• BUG: unable to handle kernel NULL pointer dereference
• Oops:
• Call Trace:
• dummy_udc
• UDC core
• unbind callback
• gadget unbind

What your security team should do

• Prioritize patching Linux hosts where untrusted local users, containers, CI jobs, developer workloads, or test harnesses can interact with USB gadget or kernel module functionality.
• Inventory systems for the dummy_hcd module and identify where USB gadget emulation is actually required.
• Disable or blacklist dummy_hcd on production systems that do not need USB gadget testing or emulation.
• Restrict kernel module loading to trusted administrators and enforce module allowlisting where supported.
• Monitor for unexpected loading of dummy_hcd, especially on servers where USB gadget emulation is not part of normal operations.
• Review kernel logs for crashes or warnings involving dummy_hcd, dummy_udc_async_callbacks, dummy_pullup, dummy_stop, gadget_setup, or USB gadget unbind activity.
• For custom kernels, backport the upstream fix and validate with stress testing of gadget bind/unbind operations.
• Treat unexplained local kernel crashes involving dummy-hcd as potential exploitation attempts, even though public exploit maturity and EPSS are currently low.