CVE-2026-64344

What it actually does

This is a Linux kernel use-after-free race condition in the USB idmouse driver. The flaw occurs during a disconnect/release race where driver-private data can be freed while code associated with mutex unlock handling may still access the mutex object. A successful trigger can corrupt kernel memory or dereference freed memory in kernel context. The most likely observable outcome is a kernel crash or denial of service, though use-after-free defects in kernel drivers can sometimes be shaped into local privilege escalation if an attacker can reliably control allocation and timing.

Why it matters to the business

Systems that load or expose the vulnerable USB idmouse driver could be crashed by a malicious or malfunctioning USB device, causing service disruption, workstation outages, or instability in kiosk, embedded, lab, or endpoint environments where USB peripherals are accepted. Current public exploitation indicators are low: EPSS is 0.00177, the issue is not in CISA KEV, is not known to be used in ransomware campaigns, and no mature public exploit is reported. Operational urgency is therefore highest for systems that allow physical USB access or support untrusted USB devices.

How an attack unfolds

An attacker needs a path to interact with the vulnerable USB idmouse driver, typically by attaching or emulating a USB device that binds to that driver. The attacker then repeatedly triggers open/release and disconnect timing windows so that the device data structure is released while mutex-related cleanup can still reference it. If the race is won, the kernel accesses freed memory. In practical terms, this may panic the system or destabilize the kernel. More advanced exploitation would require carefully grooming kernel heap allocations around the freed object and precisely controlling race timing, which is substantially harder than causing a crash and no public mature exploit is currently reported.

How to fix it

Upgrade to a Linux kernel build that includes the idmouse driver fix using kref-based lifetime management for the driver data. Because no exact affected product list or fixed package versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution, appliance vendor, or kernel branch maintainer. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the idmouse driver if not required, restricting physical USB access, enforcing USB device control policies, and preventing untrusted USB device attachment or emulation on sensitive systems.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor backport or upstream fix for the USB idmouse disconnect race. Validate both the installed package version and the currently booted kernel, because patched kernels are not effective until the system has rebooted into them. Check whether the idmouse module is present or loadable, whether it is currently loaded, and whether local policy prevents unwanted USB device binding. If a mitigation was applied, verify that the module cannot be loaded and that compatible USB devices no longer bind to the vulnerable driver.

Typical attack path

1. Gain physical, local, or device-emulation access to a Linux system that permits USB device attachment.
2. Present a USB device or emulator that causes the kernel to bind the USB idmouse driver.
3. Trigger concurrent device release and disconnect behavior repeatedly to hit the race condition.
4. Cause the driver-private data to be freed while mutex unlock or related cleanup code can still access the object.
5. Achieve kernel memory corruption or a kernel crash; in a more advanced scenario, attempt to shape memory reuse for privilege escalation.

How to detect it

Post-exploitation detection is difficult because a successful trigger may leave only kernel logs or crash artifacts rather than durable files. Review kernel logs, system journals, crash dumps, and USB audit telemetry for idmouse device binding followed by rapid disconnect/release activity, kernel oops reports, general protection faults, use-after-free diagnostics, KASAN reports, or unexplained reboots. Focus on systems with physical USB exposure or recent suspicious peripheral attachment. Useful log sources include dmesg output, systemd journal kernel messages, /var/log/kern.log, /var/log/messages, crash dump directories such as /var/crash, and endpoint USB device-control logs. If kernel crash dumping is enabled, inspect vmcore or panic reports for stack traces referencing the idmouse USB driver, USB disconnect handling, mutex unlock paths, or release routines.

• idmouse
• usb idmouse
• USB: idmouse
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• kernel BUG
• Oops:
• general protection fault
• Unable to handle kernel paging request
• mutex_unlock
• disconnect
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /proc/modules
• /sys/module/idmouse

What your security team should do

• Prioritize patching Linux systems where untrusted users can attach USB devices, including shared workstations, kiosks, lab systems, build machines, and embedded deployments.
• Confirm systems have rebooted into a fixed kernel after applying vendor updates.
• If the idmouse driver is not business-required, blacklist or disable it as a defense-in-depth measure.
• Apply USB device control policies to block unapproved Human Interface Devices and unusual USB peripherals.
• Monitor for kernel crashes, oops messages, or repeated USB connect/disconnect activity involving the idmouse driver.
• Treat exploitation likelihood as currently low because there is no KEV listing, no known ransomware use, low EPSS, and no reported mature exploit, but reassess if public proof-of-concept code appears.