CVE-2026-31758

What it actually does

This is a Linux kernel use-after-free in the USB Test and Measurement Class driver, usbtmc. When a process closes or releases a USBTMC device while USB Request Blocks are still anchored and pending, the driver may free associated state before the host controller driver completes callback handling. A local, low-privileged user with access to a USBTMC device could potentially trigger kernel memory corruption, leading to a kernel crash, denial of service, or, depending on memory layout and exploit reliability, possible local privilege escalation or kernel-level code execution.

Why it matters to the business

Successful exploitation could allow a local user or process on a Linux system to crash the host or gain elevated privileges, which may affect systems connected to USB test-and-measurement equipment, lab workstations, manufacturing stations, embedded Linux devices, and other environments where USBTMC hardware is attached. The current public exploitation signal is low: EPSS is approximately 0.0013, unchanged over 30 days, with no known CISA KEV listing, no ransomware association, and no public exploit maturity reported. Even with low broad internet risk, organizations should treat this as important for systems where untrusted users, workloads, or USB devices can interact with kernel USB drivers.

How an attack unfolds

An attacker first needs local execution on a vulnerable Linux system and access to a USBTMC device interface, commonly exposed through the usbtmc kernel driver and device nodes such as /dev/usbtmc*. The attacker opens the USBTMC device and initiates USB operations that leave URBs pending. They then trigger device release or close behavior while those URBs remain anchored. Because vulnerable kernel versions do not flush or kill those anchored URBs during usbtmc_release, a later USB completion path may reference memory that has already been freed. In the simplest case, this produces a kernel oops or panic. A more capable attacker may attempt to shape heap allocations and completion timing to turn the use-after-free into controlled kernel memory corruption, potentially escalating privileges from a local user context to root or kernel-level control.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the upstream fix for the usbtmc release path, specifically the change that flushes or kills anchored URBs by calling usbtmc_draw_down() from usbtmc_release. No exact fixed package versions were provided, so use vendor security advisories and kernel changelogs to identify the first fixed kernel for each distribution. Where immediate patching is not possible, reduce exposure by unloading or blacklisting the usbtmc module if USBTMC functionality is not required, restricting access to /dev/usbtmc* device nodes through udev permissions and group membership, preventing untrusted local users from accessing USB instrumentation devices, and enforcing physical or policy controls against untrusted USB devices.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor patch for the usbtmc_release anchored-URB cleanup issue. Check distribution kernel changelogs or source patches for references to "usb: usbtmc: Flush anchored URBs in usbtmc_release" or to usbtmc_draw_down() being called during release. Validate runtime exposure by checking whether the usbtmc module is loaded and whether USBTMC device nodes exist. Example checks include lsmod | grep usbtmc, find /dev -name 'usbtmc*', and modinfo usbtmc. If mitigation is used instead of patching, confirm the module cannot be loaded, device nodes are not present or are restricted, and untrusted users cannot access USBTMC devices.

Typical attack path

1. Obtain local code execution on a vulnerable Linux host.
2. Identify that the usbtmc driver is loaded or that /dev/usbtmc* devices are present.
3. Ensure access to a USBTMC-compatible device or malicious USB device handled by the usbtmc driver.
4. Open the USBTMC device and submit operations that create pending anchored URBs.
5. Close or release the device while URBs are still pending.
6. Trigger host controller giveback/completion handling after the usbtmc object has been released.
7. Cause a kernel crash or attempt controlled memory corruption for local privilege escalation.

How to detect it

Look for signs of kernel memory corruption or crashes around USBTMC device use. Relevant log sources include kernel logs, journald, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, audit logs for access to /dev/usbtmc*, and endpoint telemetry showing processes interacting with USBTMC devices. Search for KASAN or kernel oops messages that mention use-after-free, usbtmc_release, usbtmc, URB completion, HCD giveback, USB disconnect/release events, or crashes shortly after a user process opens and closes /dev/usbtmc*. Because no public exploit indicators or threat actors are reported, detection should focus on behavioral evidence: repeated local access to USBTMC devices followed by kernel warnings, panics, reboots, or suspicious privilege changes after device interaction.

• /dev/usbtmc0
• /dev/usbtmc1
• usbtmc
• usbtmc_release
• usbtmc_draw_down
• BUG: KASAN: use-after-free
• KASAN: use-after-free
• kernel BUG
• Oops:
• general protection fault
• use-after-free
• URB
• giveback
• usb_submit_urb
• usbcore
• usb_disconnect
• kernel panic
• Unable to handle kernel NULL pointer dereference
• Unable to handle kernel paging request

What your security team should do

• Prioritize patching Linux systems that are multi-user, run untrusted workloads, or connect to USBTMC-compatible lab, industrial, manufacturing, or test equipment.
• Inventory hosts where the usbtmc module is loaded or /dev/usbtmc* device nodes exist, and treat those as the primary exposure set.
• Apply vendor kernel updates that include the usbtmc_release anchored-URB cleanup fix; reboot systems so the fixed kernel is running.
• If patching is delayed, unload or blacklist the usbtmc module on systems that do not require USBTMC functionality.
• Restrict /dev/usbtmc* permissions to only trusted administrative or instrumentation users and review udev rules that grant broad device access.
• Monitor kernel logs for use-after-free, KASAN, slab, USB, host-controller giveback, or usbtmc-related crash messages, especially following access to USBTMC devices.
• Because EPSS is low and there is no KEV listing or known public exploit, prioritize based on local access risk and device exposure rather than internet-facing exposure.