CVE-2026-64340

What it actually does

This is a use-after-free race condition in the Linux kernel USB LEGO USB Tower driver, legousbtower. The flaw occurs during device disconnect and file release handling: mutex_unlock() may still access the mutex object after the lock is released, while a concurrent disconnect path can free the driver data. If the race is won, the kernel may access freed memory. The most likely outcome is a kernel crash or denial of service, but kernel use-after-free conditions can sometimes be shaped into local privilege escalation if an attacker can reliably control memory reuse. Exploitation requires local interaction with the affected USB driver path, typically by attaching, emulating, or rapidly disconnecting a USB device handled by this driver while the device node is in use.

Why it matters to the business

Systems using affected Linux kernels may be exposed to local denial-of-service risk if untrusted users can attach USB devices or emulate USB peripherals. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no public exploit maturity reported, and has a low EPSS score, so internet-scale exploitation is unlikely. The primary operational concern is workstation, lab, kiosk, build, or industrial systems where physical USB access or USB gadget access is possible.

How an attack unfolds

An attacker first needs access to a system running an affected Linux kernel with the legousbtower USB driver available and a way to cause a compatible USB device to bind to that driver. The attacker opens the associated device interface and then triggers a timing race by disconnecting, reconnecting, or emulating disconnect behavior while the device file is being released. Because the driver previously relied on a mutex for object lifetime management, the disconnect path can free driver data while another path still reaches mutex_unlock() and accesses the same object. A successful race can cause a kernel use-after-free. In practical terms, this is most likely to crash the kernel, but a sufficiently capable local attacker could attempt heap grooming to turn the memory corruption into code execution in kernel context.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the legousbtower driver. The fix changes object lifetime management to use kref reference counting so driver data is not freed while still reachable during release/disconnect races. Because no affected product list or exact fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory when available. If immediate patching is not possible, reduce exposure by preventing untrusted USB device attachment, disabling or blacklisting the legousbtower module if it is not required, enforcing physical port controls, and limiting local users who can interact with USB devices.

How to confirm the fix worked

Confirm that deployed kernels include the vendor patch for the legousbtower use-after-free fix. Validate exposure by checking whether the legousbtower driver is present, loadable, or loaded, and whether systems allow untrusted USB attachment. Useful checks include reviewing the running kernel version against vendor advisories, checking module presence with commands such as lsmod, modinfo legousbtower, and searching kernel configuration for LEGO USB Tower driver support. After remediation, verify that the patched kernel is running after reboot and that any temporary module blacklist or USB access-control policy remains in effect.

Typical attack path

1. Gain local physical access, local shell access with USB gadget capability, or control of a peripheral attached to the Linux system.
2. Attach or emulate a USB device that binds to the legousbtower kernel driver.
3. Open the driver-exposed device interface so the vulnerable driver data is active.
4. Trigger a race between file release and USB disconnect by rapidly closing the device while disconnecting or emulating disconnect events.
5. Cause the driver to access freed memory during mutex_unlock() after the backing object has been released.
6. Achieve a kernel crash, or in a more advanced scenario, attempt memory grooming to influence freed object reuse and escalate privileges.

How to detect it

Look for evidence of prior exploitation in kernel and system logs, especially around USB connect/disconnect events and kernel crashes. Relevant log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, audit logs for local user activity, and endpoint telemetry showing USB device insertion. Search for legousbtower driver messages, repeated USB disconnect/reconnect cycles, kernel oops or panic events, KASAN reports, slab use-after-free reports, and crashes shortly after a LEGO USB Tower or related USB device was attached. Because this vulnerability is a race condition in kernel memory handling, there may be no durable file-based artifact if exploitation only caused a crash. There are no known public threat actors, ransomware campaigns, or confirmed exploitation patterns associated with this issue based on the supplied data.

• legousbtower
• USB: legousbtower
• lego usb tower
• LEGO USB Tower
• BUG: KASAN: use-after-free
• use-after-free in legousbtower
• kernel BUG
• Oops:
• general protection fault
• slab-use-after-free
• usb disconnect
• USB disconnect
• /var/log/kern.log
• /var/log/messages
• /var/crash/
• /proc/vmcore

What your security team should do

• Prioritize patching Linux endpoints and systems where untrusted users can attach USB devices, including workstations, kiosks, lab machines, shared terminals, and systems with USB-over-IP or USB gadget exposure.
• Inventory systems for the legousbtower driver by checking loaded modules, available kernel modules, and kernel configuration.
• If the driver is not needed, blacklist or remove the legousbtower module as a defense-in-depth measure.
• Restrict physical USB access and disable unused USB ports on sensitive systems where practical.
• Monitor kernel logs for crashes, oops reports, KASAN use-after-free findings, or repeated USB connect/disconnect activity involving the legousbtower driver.
• Treat suspected exploitation as a local kernel compromise investigation if there are signs of privilege escalation, unexpected kernel crashes, or anomalous activity immediately following USB device events.
• Track distribution-specific advisories for exact fixed kernel package versions and ensure systems reboot into the corrected kernel after update.