CVE-2026-64341

What it actually does

This is a Linux kernel use-after-free race condition in the USB iowarrior driver. When an IO-Warrior USB device is disconnected while the device file is being released, driver teardown can race with mutex handling, allowing kernel memory associated with the device structure to be freed while still being accessed. In practical terms, successful exploitation can cause a kernel crash and denial of service; depending on kernel configuration, heap layout, attacker control over the USB device behavior, and available primitives, kernel memory corruption could potentially be shaped toward local privilege escalation, although no public exploit maturity is currently reported.

Why it matters to the business

Systems that load the iowarrior USB driver can be destabilized by a malicious or malfunctioning USB device, potentially causing unexpected reboots, service outages, or loss of availability on endpoints, appliances, lab systems, kiosks, or servers with exposed USB access. The current public exploitation likelihood is low, with low EPSS, no CISA KEV listing, and no known ransomware use, but organizations with physical USB exposure, untrusted peripheral use, or Linux systems that automatically load USB drivers should still treat this as a defense-in-depth kernel hardening issue.

How an attack unfolds

An attacker needs a path to interact with the vulnerable USB driver, typically by attaching or emulating an IO-Warrior-compatible USB device and triggering driver open, release, and disconnect behavior in a tight race. The attacker repeatedly opens the device node, initiates release or close operations, and disconnects or logically resets the USB device at precise timing so that disconnect cleanup and release cleanup overlap. If the race is won, the driver may free its private data while mutex unlock handling or related release logic still references the freed object. The most likely observable result is a kernel warning, KASAN use-after-free report, oops, panic, or host crash. More advanced exploitation would require converting the use-after-free into controlled kernel memory corruption, which is significantly harder and currently has no reported public exploit maturity for this issue.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the iowarrior driver lifetime-management fix using kref-based object release. Because no exact fixed package versions were provided, use vendor advisories, distribution changelogs, or kernel stable release notes to identify builds that mention this CVE, the iowarrior use-after-free disconnect race, or the relevant USB iowarrior kref fix. If the driver is not required, reduce exposure by preventing it from loading, for example by blacklisting the iowarrior kernel module, removing unused USB device support from custom kernels, or disabling untrusted USB access. For high-risk systems, combine patching with physical port controls, USB device allowlisting, kernel lockdown/hardening, and least-privilege permissions on USB character devices.

How to confirm the fix worked

Confirm that the running kernel package or custom kernel source includes the iowarrior disconnect-race fix, not merely that an installed package is present on disk. Validate with vendor package metadata, changelog entries, kernel source inspection, or module build information. Check whether the iowarrior module is loaded with commands such as lsmod, modinfo, or by inspecting /sys/module/iowarrior. If the driver is not needed and mitigation is chosen, verify that module blacklist policy is active and that the module cannot be autoloaded by plugging a matching device. Review kernel logs after testing or reboot for absence of iowarrior-related KASAN, oops, BUG, or panic messages.

Typical attack path

1. Gain physical access to a Linux system USB port or otherwise control a USB device/emulator connected to the system.
2. Present a USB device that binds to the Linux iowarrior driver or cause the iowarrior module to load.
3. Open the associated iowarrior character device from user space, if permissions allow.
4. Rapidly race device release/close activity against USB disconnect, reset, or removal events.
5. Trigger the use-after-free condition in the driver cleanup path.
6. Cause a kernel crash, denial of service, or potentially attempt further kernel exploitation if reliable memory corruption control is achieved.

How to detect it

Look for evidence of attempted or successful triggering in kernel and system logs rather than network telemetry, because exploitation is local/USB-facing. Relevant sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, kernel oops reports, endpoint USB device inventory logs, and physical access control records where available. Search for iowarrior driver load events, USB connect/disconnect/reset storms, KASAN or kernel BUG reports showing use-after-free, and kernel oops traces referencing iowarrior release or disconnect paths. Correlate timestamps with local logins, udev events, device node access, and newly attached USB peripherals. Absence of logs does not fully rule out exploitation if kernel logs were not persisted before a crash or if crash dump collection was disabled.

• iowarrior
• /sys/module/iowarrior
• /dev/usb/iowarrior
• BUG: KASAN: use-after-free
• KASAN: use-after-free
• use-after-free in iowarrior
• iowarrior_disconnect
• iowarrior_release
• USB disconnect
• usb reset
• kernel BUG at
• Oops:
• Kernel panic - not syncing

What your security team should do

• Prioritize patching Linux systems where untrusted users can attach USB devices, where USB passthrough is available, or where embedded/operational systems use IO-Warrior peripherals.
• Inventory systems with the iowarrior module present or loaded and determine whether the driver is actually required.
• If iowarrior is unused, blacklist or remove the module as a near-term mitigation while normal kernel patch cycles proceed.
• Restrict physical and logical USB access on sensitive Linux systems using port control, device allowlisting, and endpoint management policy.
• Monitor kernel logs for iowarrior, KASAN use-after-free, oops, panic, and USB disconnect/reset patterns that coincide with local user activity or unexpected peripheral attachment.
• For custom kernels or appliances, backport the upstream driver fix and regression test USB disconnect/release behavior under stress.