CVE-2026-43327

What it actually does

This is a local Linux kernel race condition in the USB dummy host controller/gadget emulation driver, dummy-hcd. A race between an emulated USB reset path and USB gadget driver unbind can cause usb_gadget_udc_reset() to be called with a NULL driver pointer after shared state is cleared out of order. The result is a kernel addressing exception/crash, causing denial of service through kernel panic or system instability. The issue requires local privileges sufficient to interact with the affected USB gadget/dummy-hcd functionality; it does not provide confidentiality or integrity impact based on the published description.

Why it matters to the business

Successful exploitation can crash affected Linux systems, interrupting workloads, development/test infrastructure, CI systems, embedded platforms, or virtualization/lab environments that use USB gadget emulation. Risk is highest where untrusted or low-privileged local users, containers with relevant device/module access, or automated test workloads can exercise USB gadget/dummy-hcd behavior. The CVSS score indicates moderate severity, EPSS is very low, it is not in CISA KEV, and no mature exploit is currently reported, so remediation should be prioritized based on whether dummy-hcd/USB gadget functionality is enabled or exposed to untrusted local users.

How an attack unfolds

An attacker first obtains local code execution on a Linux system where the dummy-hcd USB gadget emulation driver is available and usable. They then trigger concurrent USB gadget state transitions, specifically racing an emulated USB reset against gadget driver unbind activity. In the vulnerable code path, set_link_state() checks state under the dummy-hcd spinlock, but stop_activity() can temporarily drop and reacquire that lock before callback_usage is incremented. During that gap, another thread can clear the active driver pointer. When execution resumes, usb_gadget_udc_reset() may be invoked with a NULL driver argument, producing a kernel addressing exception and crashing the system. Exploitation is primarily a reliability/availability attack and is likely to be easiest in environments where an attacker can load or access dummy-hcd and manipulate USB gadget binding operations.

How to fix it

Apply the vendor-provided Linux kernel update that includes the dummy-hcd synchronization fix, which increments callback_usage before stop_activity() in the affected reset path. Because no fixed version list was provided, track the fix through the relevant distribution kernel advisory, upstream stable kernel release notes, or vendor backport for CVE-2026-43327. Where immediate patching is not possible, reduce exposure by disabling or preventing loading of the dummy-hcd module if it is not required, restricting access to USB gadget interfaces and configfs, limiting module loading privileges, and preventing untrusted local users or containers from accessing USB gadget/emulation capabilities. Reboot into the patched kernel after installation; merely installing a kernel package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated to a vendor build containing the fix. Check distribution advisories or changelogs for references to CVE-2026-43327, dummy-hcd, set_link_state(), stop_activity(), or usb_gadget_udc_reset(). Verify whether the dummy_hcd module is present or loaded using kernel module inventory tools, and confirm it is blocked or absent on systems that do not require USB gadget emulation. For validation in test environments, reproduce the workload that previously exercised USB gadget bind/unbind and reset behavior and confirm there are no kernel oops/panic messages involving dummy_hcd or usb_gadget_udc_reset().

Typical attack path

1. Gain local access to an affected Linux system with sufficient privileges to interact with USB gadget/dummy-hcd functionality.
2. Confirm that dummy-hcd or USB gadget emulation is present, loadable, or already active.
3. Create repeated USB gadget bind/unbind and emulated reset operations to increase race probability.
4. Win the race between reset handling and driver unbind so the driver pointer is cleared before usb_gadget_udc_reset() is called.
5. Trigger a kernel addressing exception, oops, panic, or hard crash, resulting in local denial of service.

How to detect it

Review kernel logs and persistent system journals for crashes or warnings involving dummy-hcd, USB gadget reset handling, or NULL driver/reset paths. Useful sources include dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump records, kdump/vmcore metadata, and kernel panic monitoring. Look for oops, panic, general protection fault, NULL pointer dereference, or addressing exception entries near function names such as usb_gadget_udc_reset, set_link_state, stop_activity, or dummy_hcd. Also review audit and shell history, where available, for suspicious loading of dummy_hcd, repeated gadget bind/unbind operations under configfs, or changes to module blacklists. Because the vulnerability causes denial of service rather than persistent compromise, indicators are most likely to be transient kernel crash artifacts and repeated local activity immediately before reboots or panics.

• usb_gadget_udc_reset
• dummy_hcd
• dummy-hcd
• set_link_state
• stop_activity
• drivers/usb/gadget/udc/core.c
• drivers/usb/gadget/udc/dummy_hcd.c
• NULL pointer dereference
• addressing exception
• Kernel panic
• Oops:
• modprobe dummy_hcd
• insmod dummy_hcd
• /sys/kernel/config/usb_gadget
• /sys/module/dummy_hcd

What your security team should do

• Inventory Linux systems where dummy-hcd, USB gadget emulation, USB/IP testing, kernel fuzzing, CI hardware emulation, or embedded USB gadget workflows are used.
• Prioritize patching systems that allow local shell access by untrusted users or run containers/workloads with access to kernel module loading, configfs, or USB gadget interfaces.
• Apply the appropriate vendor kernel update and reboot into the patched kernel.
• If dummy-hcd is unnecessary, blacklist or otherwise prevent loading of the dummy_hcd module as a compensating control.
• Restrict module loading and access to USB gadget/configfs interfaces to trusted administrators only.
• Monitor kernel logs for oops, panic, NULL pointer, or addressing exception messages involving dummy_hcd, set_link_state, stop_activity, or usb_gadget_udc_reset.
• Treat unexplained crashes on systems using USB gadget emulation as potentially security-relevant until kernel logs are reviewed.