CVE-2026-64343

What it actually does

This is a Linux kernel use-after-free flaw in the USB ldusb driver caused by a race between device disconnect handling and file release handling. The vulnerable lifetime management allows driver-private data, including a mutex object, to be freed while code may still access it during or after mutex_unlock(). At a technical level, a local attacker able to interact with an affected ldusb-supported USB device, or a malicious USB device that can trigger rapid disconnect/release timing, may cause kernel memory corruption. The most likely impact is a kernel crash or denial of service; depending on allocator state, kernel hardening, and exploit reliability, memory corruption bugs of this class can sometimes be shaped toward privilege escalation, though no public exploit maturity is currently reported.

Why it matters to the business

The primary operational risk is unexpected Linux host crashes when vulnerable systems interact with affected USB devices, which can disrupt workstations, lab systems, kiosks, embedded Linux devices, or servers where USB access is available. Because exploitation appears to require local or physical USB interaction and EPSS is low at 0.00177, broad internet-scale exploitation is unlikely. It is not listed in CISA KEV and is not known to be used in ransomware campaigns, but kernel memory corruption should still be prioritized on systems where untrusted users can access USB ports or where USB pass-through is enabled.

How an attack unfolds

An attacker first needs access to a Linux system running a vulnerable kernel with the ldusb driver present and reachable through a compatible USB device. The attacker then causes user-space interaction with the ldusb device node while racing device removal or disconnect behavior against file release paths. In the vulnerable code path, disconnect may free the driver data while release processing still reaches mutex_unlock(), which can access the already-freed mutex structure. Successful triggering can corrupt kernel memory or crash the system. Practical exploitation for privilege escalation would require precise timing, heap grooming, and bypassing kernel mitigations such as KASAN-disabled production builds, slab freelist protections, SMEP/SMAP, KASLR, and lockdown policies. No public exploit maturity is currently indicated.

How to fix it

Update the Linux kernel to a version that includes the ldusb lifetime-management fix using kref-based release handling. Where vendor kernel packages are used, apply the relevant distribution security update rather than only relying on upstream version numbers. If immediate patching is not possible, reduce exposure by disabling or blacklisting the ldusb driver where it is not required, restricting physical USB access, disabling USB pass-through for untrusted workloads, and enforcing device-control policies for removable hardware. Example temporary mitigation: add a modprobe blacklist entry for the ldusb module if the driver is unused, then rebuild initramfs if the distribution requires it and reboot. Mitigations should be treated as temporary because the correct fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for this issue, not just that patched packages are installed on disk. Validate with uname -r, distribution package changelogs, kernel security advisories, and reboot status. Check whether the ldusb module is present or loaded using lsmod, modinfo ldusb, and module inventory tooling. On systems where ldusb is not needed, confirm the module cannot be loaded after mitigation by attempting modprobe -n -v ldusb and checking blacklist policy. For patched systems that require the driver, perform controlled USB attach/detach testing only in a non-production environment and monitor dmesg/journal logs for KASAN, use-after-free, general protection fault, NULL pointer dereference, slab corruption, or kernel oops messages referencing ldusb.

Typical attack path

1. Gain local physical access to a Linux system, or access to a virtualization/container setup that exposes USB devices or USB pass-through.
2. Connect or emulate an ldusb-supported USB device so the vulnerable kernel driver is loaded and a device node is created.
3. Open or otherwise interact with the ldusb device from user space.
4. Rapidly trigger USB disconnect/removal while causing the file release path to execute.
5. Win the race so disconnect frees the driver-private object while release processing still accesses the mutex during unlock handling.
6. Cause kernel memory corruption, usually resulting in a system crash; with additional exploit work, attempt to convert corruption into kernel-code execution or privilege escalation.

How to detect it

Look for evidence of prior triggering in kernel and system logs rather than network telemetry, because exploitation is local/physical and USB-based. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dump records, kdump/vmcore data, endpoint telemetry, USB device inventory logs, and audit logs showing access to ldusb device nodes. Search for kernel oops, panic, KASAN, slab corruption, general protection fault, or use-after-free messages occurring near USB disconnect events and referencing ldusb. Also review sequences where an ldusb-compatible USB device is repeatedly connected and disconnected shortly before a crash. There are no known public actor-specific or ransomware-specific indicators for this issue, and no reliable network indicators are expected.

• ldusb
• BUG: KASAN: use-after-free
• use-after-free in ldusb
• USB: ldusb
• ldusb_disconnect
• ld_usb_release
• kernel BUG at drivers/usb/misc/ldusb.c
• general protection fault
• kernel NULL pointer dereference
• slab-use-after-free
• Oops:
• Kernel panic
• usb disconnect
• USB disconnect
• /var/log/kern.log
• /var/log/messages
• journalctl -k
• dmesg
• /dev/usb/ldusb

What your security team should do

• Prioritize patching Linux systems where users, contractors, lab personnel, kiosk users, or attackers could physically access USB ports.
• Patch virtualization hosts, developer workstations, build machines, and lab systems that allow USB pass-through or arbitrary USB device attachment.
• Inventory systems with the ldusb module available or loaded, and determine whether the driver is required.
• Blacklist or disable ldusb on systems that do not need it, especially in high-assurance or physically exposed environments.
• Review endpoint and physical security controls for removable USB devices, including port control, device allowlisting, and BIOS/UEFI USB restrictions where appropriate.
• Monitor kernel logs for crashes or memory-safety warnings involving ldusb, usb disconnect events, KASAN, kernel oops, or slab corruption.
• Because the issue is not KEV-listed, has low EPSS, and has no known public exploit maturity, treat it as a targeted/local exposure risk rather than an internet-facing emergency, unless USB access is broadly available.