CVE-2026-63904

What it actually does

This is a Linux kernel memory-safety flaw in the USB Test and Measurement Class (USBTMC) driver. A USBTMC device using an interrupt-IN endpoint can return a notification URB shorter than the driver expects. Before the fix, the driver accessed notification header bytes without first verifying that URB actual_length contained enough data. A malformed or malicious USBTMC device can therefore cause an out-of-bounds read or make the kernel process stale data left in the buffer from a previous notification. The most likely outcomes are kernel instability, driver misbehavior, or denial of service; limited information exposure from stale kernel/driver buffer contents may also be possible depending on runtime conditions.

Why it matters to the business

Systems that connect to USB-based test, measurement, lab, industrial, or instrumentation devices may be disrupted by a malformed or malicious peripheral. Because exploitation requires interaction with a USBTMC-class device or an equivalent USB path, the risk is highest for workstations, lab machines, manufacturing stations, and embedded Linux systems that accept physical USB devices. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, environments with untrusted USB access or supply-chain exposure to peripherals should still treat it as a hardening priority.

How an attack unfolds

An attacker needs the target Linux system to load the usbtmc driver for a USBTMC-compatible device. This can be done by connecting a malicious USB device, compromising firmware on a legitimate instrument, or presenting an emulated USBTMC device through a virtualization, USB-over-IP, or test harness path. Once the device is enumerated and the usbtmc driver submits an interrupt-IN URB for optional notifications, the malicious device returns a notification shorter than the expected two-byte header. Vulnerable kernels then read beyond the valid bytes in the URB buffer or process stale data from a prior notification. Depending on kernel configuration and memory layout, this may trigger a kernel warning, KASAN report, oops, device-driver malfunction, or system crash. There is no public exploit maturity indicated for this issue, and exploitation is constrained by USB/device access rather than remote network reachability.

How to fix it

Upgrade to a Linux kernel build that includes the usbtmc fix, which validates interrupt-IN URB actual_length before reading notification headers and resubmits the URB when too little data is present. Because no exact fixed package versions were provided, use the latest security kernel from the operating system or appliance vendor and verify that the patch for "usb: usbtmc: check URB actual_length for interrupt-IN notifications" is included. Where immediate patching is not possible, reduce exposure by restricting physical USB access, disabling unused USB ports, preventing automatic use of untrusted USB devices, blocking USB-over-IP paths from untrusted sources, unloading or blacklisting the usbtmc module if USBTMC devices are not required, and using USB device allowlisting for approved instrumentation only.

How to confirm the fix worked

Confirm the running kernel includes the vendor security update or the upstream usbtmc actual_length validation patch. Validate with package-manager advisory data, kernel changelogs, or source inspection for a length check before parsing interrupt notification headers in the usbtmc interrupt handling path. On systems that do not require USBTMC, confirm the usbtmc module is not loaded and is blocked from autoloading. On systems that do require it, test approved instruments after patching to ensure normal measurement workflows still function. Review kernel logs after connecting USBTMC devices and confirm there are no KASAN, oops, WARN, or usbtmc-related errors triggered by short interrupt notifications.

Typical attack path

1. Gain physical, firmware, virtual USB, or USB-over-IP control over a device path presented to the Linux host.
2. Present a USB device that matches the USBTMC class so the kernel loads or uses the usbtmc driver.
3. Advertise or use an optional interrupt-IN endpoint for USBTMC notifications.
4. Send a malformed interrupt-IN notification with URB actual_length shorter than the expected notification header.
5. Cause the vulnerable driver to read beyond the valid notification bytes or reuse stale buffer contents.
6. Observe or induce kernel instability, driver malfunction, information exposure side effects, or denial of service.

How to detect it

Retrospective detection is difficult because the malformed notification is exchanged at the USB driver level and may not leave application-layer evidence. Focus on kernel, audit, and endpoint telemetry. Review journald, syslog, dmesg, crash dumps, pstore, kdump, and EDR telemetry for kernel warnings or crashes involving usbtmc, USBTMC enumeration, interrupt URBs, KASAN out-of-bounds reports, general protection faults, kernel oopses, or panics shortly after USB device attachment. Correlate with USB inventory events such as new vendor/product IDs, serial numbers, instrument firmware changes, or USB-over-IP sessions. If KASAN or debug kernels are used in lab environments, search specifically for out-of-bounds reads in usbtmc interrupt handling. For production systems, look for unexplained reboots, kernel taints, or driver errors following connection of test-and-measurement devices. Network logs are generally not useful unless USB devices are forwarded over IP or managed through remote lab infrastructure.

• usbtmc
• USBTMC
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• BUG: KASAN
• kernel BUG
• Oops:
• general protection fault
• Kernel panic
• panic: Fatal exception
• usbcore: registered new interface driver usbtmc
• usbcore: deregistering interface driver usbtmc
• new high-speed USB device
• new full-speed USB device
• New USB device found
• idVendor=
• idProduct=
• usb-storage is not a valid indicator for this issue; prioritize USBTMC/usbtmc events
• /sys/bus/usb/drivers/usbtmc
• /sys/module/usbtmc
• /lib/modules/*/kernel/drivers/usb/class/usbtmc.ko
• /lib/modules/*/kernel/drivers/usb/class/usbtmc.ko.xz
• /lib/modules/*/kernel/drivers/usb/class/usbtmc.ko.zst
• modprobe usbtmc
• insmod usbtmc
• rmmod usbtmc

What your security team should do

• Patch Linux kernels on systems that connect to USB test, measurement, lab, manufacturing, or industrial instrumentation.
• Inventory hosts where the usbtmc module is loaded or where USBTMC-class devices are attached.
• Restrict physical USB access and enforce USB device allowlisting on workstations and embedded systems that operate in shared, lab, or production areas.
• Blacklist or remove the usbtmc module on systems that do not need USBTMC functionality.
• Review recent kernel logs for usbtmc, USB enumeration, KASAN, oops, or panic events around the time USB instruments were connected.
• Treat unexpected USBTMC devices, newly observed USB vendor/product IDs, or unexplained instrument firmware changes as investigation triggers.
• Because the issue is not KEV-listed, not associated with ransomware, and has low EPSS, prioritize internet-facing critical vulnerabilities first, but include this in kernel patch cycles for USB-exposed systems.