CVE-2026-64342

What it actually does

This is a use-after-free flaw in the Linux kernel USB iowarrior driver. When write URBs are submitted and the device is closed, those URBs may remain active; if the USB device is then disconnected, the completion handler can later operate on memory that has already been freed. At minimum, this can trigger a kernel crash or memory corruption. Depending on kernel configuration, timing, allocator behavior, and attacker control over the USB interaction, memory corruption bugs of this class may sometimes be shaped into local privilege escalation or kernel-level code execution, though no public exploit maturity is currently indicated.

Why it matters to the business

Systems that load the affected Linux USB iowarrior driver may be exposed to local or physically adjacent attacks that can crash the host or potentially compromise the kernel. The operational risk is highest for workstations, kiosks, embedded systems, industrial systems, or lab environments where untrusted USB devices can be connected. Current public exploitation likelihood appears low: EPSS is low, the issue is not listed in CISA KEV, and no known ransomware use is indicated. However, kernel memory corruption flaws should still be remediated during normal patch cycles, especially on systems where USB access is difficult to control.

How an attack unfolds

An attacker needs the vulnerable iowarrior driver to be present and reachable, typically by connecting or emulating a compatible USB I/O-Warrior device. The attacker triggers writes to the device so the driver submits USB Request Blocks. Because the vulnerable logic does not always cancel submitted write URBs before disconnect handling frees related objects, the attacker then disconnects or forces removal of the device at a carefully chosen time. When a pending URB completes after the disconnect path has released driver state, the completion callback accesses freed memory. The most likely observable result is a kernel oops, panic, or host crash. In a more advanced exploitation scenario, the attacker would attempt to control heap reuse after the free and influence the stale completion handler to corrupt kernel memory in a useful way.

How to fix it

Apply the Linux kernel update that contains the iowarrior disconnect fix. If using a vendor kernel, upgrade to the fixed kernel package provided by the operating system or appliance vendor rather than relying only on upstream source status. Reboot into the patched kernel and confirm the running kernel version changed. Where immediate patching is not possible, reduce exposure by preventing untrusted USB access, disabling or blacklisting the iowarrior driver if it is not required, restricting access to device nodes associated with USB misc drivers, and enforcing physical port controls or USB device authorization policies. Example mitigations may include removing the module if loaded and not needed, adding a modprobe blacklist entry for the iowarrior module, or using USBGuard or equivalent allowlisting to block unknown USB devices.

How to confirm the fix worked

Confirm remediation by verifying that the system is running a vendor kernel version that includes the fix for this issue, not merely that an updated package is installed. Check whether the iowarrior driver is present or loaded using kernel module inventory commands such as lsmod, modinfo, or distribution package metadata. Validate that unneeded systems cannot load the driver after mitigation by attempting a controlled module load check or reviewing modprobe blacklist policy. For exposed systems, verify USB device control policy is active and that only approved devices are allowed. If kernel source or build metadata is available, confirm the iowarrior disconnect path unconditionally stops submitted write URBs before freeing related state.

Typical attack path

1. Gain local physical access to a Linux system, or control a USB device connected to it.
2. Connect or emulate a USB device handled by the Linux iowarrior driver.
3. Cause user space or attacker-controlled interaction to submit writes through the driver.
4. Trigger a device disconnect, reset, or removal while write URBs remain pending.
5. Race the pending URB completion against driver teardown so the completion handler references freed memory.
6. Cause a kernel crash, or attempt further heap manipulation to turn the memory corruption into privilege escalation.

How to detect it

Review kernel, system, and crash logs for evidence of suspicious USB attach/detach activity followed by kernel faults involving the iowarrior driver. Useful log sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, audit logs for access to USB device nodes, USB authorization or USBGuard logs, and kernel crash dump facilities such as kdump, vmcore, apport, ABRT, or systemd-coredump where applicable. Look for sequences where an I/O-Warrior USB device is connected, write activity occurs, the device is disconnected or reset, and the kernel reports an oops, panic, KASAN use-after-free, slab corruption, general protection fault, or NULL/invalid pointer dereference in or near iowarrior driver functions. Also investigate unexpected reboots or watchdog resets immediately following USB events. There are no known named threat actors or public exploitation campaigns indicated, so detection should focus on host forensic artifacts and anomalous USB behavior rather than network indicators.

• iowarrior
• iowarrior_write_callback
• drivers/usb/misc/iowarrior.c
• BUG: KASAN: use-after-free
• use-after-free
• kernel BUG
• Oops:
• general protection fault
• slab-use-after-free
• USB disconnect
• usb disconnect
• USB device reset
• usbfs
• /var/log/kern.log
• /var/log/messages
• /sys/bus/usb/drivers/iowarrior
• /dev/usb/iowarrior

What your security team should do

• Prioritize patching systems where untrusted users can connect USB devices, including shared workstations, kiosks, labs, industrial consoles, and embedded Linux deployments.
• Inventory Linux systems for the iowarrior driver and determine whether it is loaded, available as a module, or built into the kernel.
• If the driver is not operationally required, disable or blacklist it as a defense-in-depth measure.
• Deploy or enforce USB device allowlisting on systems where physical access cannot be fully controlled.
• Monitor kernel logs for crashes, KASAN reports, or oops messages involving iowarrior, USB disconnects, or use-after-free conditions.
• Treat unexpected kernel crashes following USB device insertion or removal as potentially suspicious and preserve logs and crash dumps for analysis.
• Track vendor advisories for exact fixed kernel package versions, since no product-specific fixed versions were provided in the input.
• Because EPSS is low, KEV is false, and exploit maturity is listed as none, schedule remediation according to kernel patch policy unless the environment has high USB exposure.