CVE-2026-43429

What it actually does

This is a local denial-of-service flaw in the Linux kernel USB Test and Measurement Class (usbtmc) driver. The driver accepts user-controlled timeout values through ioctl operations and passes them to usb_bulk_msg(), which waits in an unkillable kernel sleep. A local user with access to a usbtmc device node can provide an excessively long timeout and trigger a USB bulk operation that can leave a kernel thread stuck indefinitely. The primary impact is availability degradation: blocked kernel threads, hung user processes interacting with USBTMC devices, and potential system instability or service disruption where USB-connected instruments are used.

Why it matters to the business

Systems that use Linux hosts to control USB-connected test, measurement, lab, manufacturing, or industrial instrumentation may be disrupted by a local user or compromised local process. The flaw does not enable remote code execution or data theft by itself, but it can interrupt operational workflows, block access to connected instruments, and require service restarts or host reboots to recover. Because exploitation requires local privileges and access to the relevant device, broad internet-scale risk is low, consistent with the low EPSS score and no known KEV listing; however, operational impact can be high in environments that rely on USBTMC devices for production, QA, research, or monitoring.

How an attack unfolds

An attacker first obtains local code execution on a Linux system where the usbtmc driver is loaded and a USBTMC-compatible device is present or accessible. The attacker identifies a device node such as a /dev/usbtmc* interface and confirms they have permission to open it. They then issue the relevant ioctl or I/O operation with an attacker-chosen timeout value that is excessively long. In vulnerable kernels, the usbtmc driver uses that timeout with usb_bulk_msg(), which enters an unkillable wait. Because the wait cannot be interrupted normally, the kernel thread and associated process can remain hung for an extended period or indefinitely. Repeating this action can tie up resources, disrupt legitimate USBTMC communication, and degrade host availability until the condition clears, the device is reset, the driver is unloaded, or the system is rebooted.

How to fix it

Upgrade to a Linux kernel build that includes the usbtmc change replacing affected usb_bulk_msg() calls with usb_bulk_msg_killable() for user-specified timeouts. Because no exact fixed package versions were provided, use the fixed kernel versions supplied by the relevant Linux distribution or kernel vendor and prioritize systems where USBTMC devices are connected or where the usbtmc module is loaded. If immediate patching is not possible, reduce exposure by restricting access to /dev/usbtmc* device nodes, removing untrusted users from groups that can access USB devices, disabling or blacklisting the usbtmc module where it is not required, and physically or logically limiting access to USBTMC instruments. Avoid relying on process termination alone as a recovery method because the vulnerable wait path may be unkillable; driver reset, device removal, or reboot may be required after exploitation.

How to confirm the fix worked

Confirm the running kernel contains the vendor fix for the usbtmc driver, not merely that an updated package is installed. Validate with the distribution’s kernel changelog, package advisory, or source patch history showing use of usb_bulk_msg_killable() in the usbtmc code path for user-specified timeouts. Check whether exposure exists by determining if the usbtmc module is loaded and whether /dev/usbtmc* device nodes are present and accessible to non-administrative users. After patching, reboot into the fixed kernel and verify the active kernel version with uname -r. For mitigation validation, confirm unneeded systems do not load the usbtmc module, device node permissions are restrictive, and nonessential users cannot open USBTMC device files.

Typical attack path

1. Gain local access to a Linux system, either as a legitimate low-privileged user or through a previously compromised account.
2. Check whether the usbtmc kernel driver is loaded or whether USBTMC device nodes such as /dev/usbtmc0 exist.
3. Open an accessible USBTMC device node.
4. Submit an ioctl or USBTMC operation using an excessively long user-controlled timeout value.
5. Cause the vulnerable driver path to call usb_bulk_msg() with an unkillable wait.
6. Leave a kernel thread and associated user process stuck, disrupting USBTMC device access or system availability.
7. Repeat the action to increase operational disruption or force administrative recovery actions such as driver reset or reboot.

How to detect it

Look for signs of local abuse or attempted disruption on Linux hosts where USBTMC devices are present. Useful sources include auditd logs for access to /dev/usbtmc* device nodes, shell history and EDR telemetry for programs repeatedly opening USBTMC devices, kernel logs for USBTMC or USB disconnect/reset activity, process listings showing tasks stuck in uninterruptible sleep state, and system monitoring showing hung I/O involving USB test equipment. Investigate users or processes that open /dev/usbtmc* and then remain in D state, cannot be killed, or coincide with loss of communication to USB instruments. Since this flaw does not produce a unique network signature and is local-only, detection should focus on host telemetry, device access auditing, and anomalous process states rather than perimeter logs. If threat hunting historical exploitation, correlate timestamps of USBTMC device failures, kernel messages mentioning usbtmc or USB bulk transfers, and local commands or binaries interacting with /dev/usbtmc* shortly before the outage.

• /dev/usbtmc0
• /dev/usbtmc1
• /dev/usbtmc2
• /sys/bus/usb/drivers/usbtmc
• usbtmc
• usb_bulk_msg
• D state
• uninterruptible sleep
• modprobe usbtmc
• /etc/modprobe.d/blacklist-usbtmc.conf

What your security team should do

• Prioritize patching Linux systems that control USB test, measurement, lab, manufacturing, or industrial equipment using USBTMC devices.
• Inventory systems with the usbtmc kernel module loaded or /dev/usbtmc* device nodes present.
• Apply the vendor-provided fixed kernel and reboot to ensure the fixed kernel is active.
• Restrict permissions on /dev/usbtmc* so only trusted service accounts or operators can access USBTMC devices.
• Disable or blacklist the usbtmc module on systems that do not require USBTMC functionality.
• Review local user and service account access on hosts connected to USBTMC instruments, especially shared lab or build systems.
• Monitor for repeated hung processes, uninterruptible sleep states, or operational incidents involving USBTMC device access.
• Because the vulnerability is not listed in CISA KEV and has low EPSS, treat it as lower internet-facing urgency but higher priority for operational technology, lab automation, and production test environments where availability matters.