CVE-2026-43428

What it actually does

This flaw affects Linux kernel USB core helper APIs that perform synchronous USB control, bulk, and interrupt transfers using uninterruptible waits. Callers could supply excessively large or negative timeout values, causing a task to remain stuck in an unkillable sleep for a very long or effectively indefinite period while waiting on a USB device. The result is a local denial of service: affected tasks cannot be terminated normally, resources may remain tied up, and repeated triggering can degrade system availability. The upstream fix caps these unkillable synchronous USB timeouts at 60 seconds and treats negative timeout values like zero, using the maximum allowed timeout.

Why it matters to the business

Systems that allow local users, local services, or device-facing software to interact with USB functionality may experience hung processes and reduced availability if the flaw is triggered. This is most relevant to workstations, embedded systems, kiosks, industrial/OT endpoints, appliances, and servers using attached USB devices. Although exploitation requires local access or local code execution and there is no indication of known exploitation or ransomware use, the operational impact can still be disruptive where physical USB interaction or USB-dependent services are important.

How an attack unfolds

An attacker first needs local privileges sufficient to run code that can interact with a vulnerable USB path, driver, or subsystem. They then cause code using usb_control_msg(), usb_bulk_msg(), or usb_interrupt_msg() to issue a synchronous USB transfer with an unlimited, very large, or negative timeout value against a target USB device or emulated USB endpoint that does not respond as expected. Because the affected waits are uninterruptible, the calling task can become stuck and cannot be killed through normal signal handling. By repeating the action or targeting important USB-dependent processes, the attacker can consume resources, leave tasks permanently hung until the device is removed or the system is recovered, and reduce service availability.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the usbcore fix limiting unkillable synchronous USB timeouts to 60 seconds. Because fixed versions vary by distribution and kernel branch, use the kernel package version identified by the relevant Linux distribution, appliance vendor, or embedded platform supplier as containing the backported fix for this issue. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted code execution, disabling or controlling USB access where feasible, using USB device authorization policies, and removing untrusted or unnecessary USB devices. For custom kernels or downstream products, ensure the patch caps timeout values in usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() and normalizes negative timeout values to the maximum allowed timeout behavior.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not only that an updated package is installed; verify with commands such as `uname -a` and distribution package tooling after reboot. Review vendor advisories or kernel changelogs for the USB core change that limits synchronous unkillable timeouts to 60 seconds. On systems with custom kernels, inspect the usbcore implementation to confirm timeout clamping is present for usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg(). Operationally, validate that USB-related tasks no longer remain indefinitely in uninterruptible sleep when a USB transfer stalls; any affected task should resume or fail after the capped timeout rather than requiring device removal or reboot.

Typical attack path

1. Obtain local access to a Linux system or the ability to run code in a local context that can interact with USB devices or USB-facing drivers.
2. Identify a vulnerable kernel version where usbcore synchronous USB message timeout values are not capped.
3. Attach, emulate, or interact with a USB device/path that can cause a synchronous USB transfer not to complete promptly.
4. Trigger a call path using usb_control_msg(), usb_bulk_msg(), or usb_interrupt_msg() with an excessively long, unlimited, or negative timeout value.
5. Cause the calling task to enter an uninterruptible wait that cannot be killed normally.
6. Repeat or sustain the condition to degrade system responsiveness, tie up resources, or disrupt USB-dependent services.

How to detect it

There are no public, specific exploitation indicators for this issue, and it is not listed as known exploited. Detection should focus on signs of attempted or successful local denial of service through USB-related uninterruptible waits. Review kernel logs, system journals, and endpoint telemetry for hung task warnings, blocked processes in `D` state, USB transfer errors, repeated USB disconnect/connect events, and processes stuck after interacting with USB devices. Useful sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, EDR process state telemetry, audit logs for local command execution, and physical/device management logs showing recently attached USB hardware. Correlate the timing of hung-task messages with USB device insertion events, new local user sessions, suspicious local processes, or test utilities interacting with USB endpoints. For forensic triage, collect task stacks via SysRq or crash dumps where available and look for blocked kernel stacks involving usbcore synchronous message paths such as usb_control_msg, usb_bulk_msg, or usb_interrupt_msg.

• INFO: task
• blocked for more than
• D state
• uninterruptible sleep
• usb_control_msg
• usb_bulk_msg
• usb_interrupt_msg
• usbcore
• usb
• USB disconnect
• new full-speed USB device
• new high-speed USB device
• new SuperSpeed USB device
• device descriptor read/64, error
• unable to enumerate USB device

What your security team should do

• Prioritize patching Linux systems where untrusted local users, shared workloads, physical USB access, or USB-dependent operational processes are present.
• Use vendor kernel advisories to identify the exact fixed kernel package for each distribution or appliance, then reboot systems to activate the fixed kernel.
• Restrict local code execution and shell access on systems that cannot be patched immediately.
• Apply USB control measures such as disabling unused USB ports, blocking untrusted USB devices, or enforcing USB device authorization on sensitive endpoints.
• Monitor for repeated hung tasks in uninterruptible sleep involving USB-related processes or kernel messages, especially after new USB devices are connected.
• For embedded, appliance, or custom-kernel deployments, ensure downstream maintainers have backported the usbcore timeout cap rather than relying only on upstream version numbers.