CVE-2026-64455

What it actually does

This vulnerability is a use-after-free flaw in the Linux kernel USB chaoskey driver release path. When a chaoskey device file is closed after the underlying USB device has already been unplugged, the driver can reference a usb_interface structure that has already been freed. The known trigger occurs in a debugging log statement in chaoskey_release(), producing a kernel memory safety violation such as a KASAN slab-use-after-free report. Based on the available description, the most likely impact is local kernel crash, warning, or denial of service on systems using the affected driver and hardware path; practical privilege escalation or remote exploitation is not indicated by the current public information.

Why it matters to the business

Organizations running Linux systems with the affected chaoskey USB driver could experience local system instability or crashes if the vulnerable device lifecycle is triggered. The exposure is narrow because exploitation requires local interaction with a relevant USB device and a specific unplug/close sequence, EPSS is very low, it is not listed in CISA KEV, and no mature public exploit is reported. Business risk is therefore primarily operational availability for specialized workstations, labs, embedded systems, or servers that attach chaoskey-compatible USB hardware.

How an attack unfolds

An attacker needs local access, or the ability to control a process that opens the chaoskey device node, along with the ability to cause or coordinate USB device removal. The attacker opens the chaoskey character device, unplugs or otherwise disconnects the USB device so the kernel releases the associated interface object, and then closes the still-open file descriptor. During close, chaoskey_release() executes a debug logging path that dereferences the stale usb_interface pointer after it has been freed. On vulnerable kernels this can trigger a kernel use-after-free report, warning, or crash. There is no current indication that this issue is remotely exploitable or being used by known threat actors.

How to fix it

Apply the vendor kernel update that includes the upstream fix for the USB chaoskey driver. The fix removes the unsafe debug statement that referenced the freed interface after chaoskey_free() returns. If a patched kernel package is not yet available, mitigate by preventing use of the chaoskey driver where it is not required: unload or blacklist the chaoskey kernel module, restrict physical and administrative access to USB ports, and limit permissions on relevant device nodes. Systems that do not load the chaoskey driver or do not use chaoskey-compatible USB devices are unlikely to be exposed to the known trigger path.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for the chaoskey driver use-after-free in chaoskey_release(). Validate package status through the Linux distribution’s kernel advisory and installed kernel version, then reboot into the patched kernel. Check whether the chaoskey module is present or loaded using commands such as lsmod, modinfo chaoskey, and inspection of /sys/module/chaoskey. If mitigation is used instead of patching, verify the module is blacklisted and not loaded after reboot. Kernel logs should no longer show KASAN, use-after-free, oops, or panic messages referencing chaoskey_release(), dev_driver_string(), __dynamic_dev_dbg(), or drivers/usb/misc/chaoskey.c during USB disconnect and close testing.

Typical attack path

1. Identify a Linux system with the chaoskey USB driver available and a compatible device present or attachable.
2. Obtain local interactive access or code execution sufficient to open the chaoskey device node.
3. Open the chaoskey device file and keep the file descriptor active.
4. Disconnect or force removal of the underlying USB device so the kernel frees the associated usb_interface structure.
5. Close the previously opened device file to trigger chaoskey_release().
6. Cause a kernel use-after-free condition, potentially resulting in a kernel warning, oops, panic, or denial of service depending on kernel configuration and runtime behavior.

How to detect it

Review kernel and system logs for evidence that the chaoskey driver fault path has already been triggered. Relevant sources include dmesg, journald kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump records, kdump/vmcore artifacts, and endpoint telemetry that captures kernel oops or panic events. Search for KASAN slab-use-after-free reports, call traces mentioning chaoskey_release(), dev_driver_string(), __dynamic_dev_dbg(), or drivers/usb/misc/chaoskey.c, and USB disconnect events immediately followed by close-path kernel warnings. Also review audit or EDR telemetry for local processes repeatedly opening chaoskey device nodes around the time of USB disconnects or kernel crashes. No public threat actor-specific indicators are currently associated with this vulnerability.

• BUG: KASAN: slab-use-after-free in dev_driver_string
• slab-use-after-free in dev_driver_string
• chaoskey_release
• drivers/usb/misc/chaoskey.c
• __dynamic_dev_dbg
• dev_driver_string
• USB: chaoskey
• chaoskey
• /sys/module/chaoskey
• modprobe chaoskey
• KASAN: slab-use-after-free

What your security team should do

• Prioritize normal kernel patch deployment rather than emergency response unless the organization uses chaoskey USB devices in sensitive or availability-critical systems.
• Inventory Linux endpoints, lab systems, embedded devices, and servers for the loaded chaoskey module and attached chaoskey-compatible USB devices.
• Patch affected systems with the appropriate vendor kernel update and reboot to ensure the fixed kernel is active.
• Where the hardware is not required, blacklist or remove the chaoskey module to eliminate exposure to the vulnerable code path.
• Restrict physical USB access and local shell access on systems where kernel attack surface reduction is important.
• Monitor kernel logs for use-after-free, KASAN, oops, or panic events involving the chaoskey driver, especially on systems with USB device churn.
• Treat any repeated local triggering as suspicious operational abuse, but calibrate alert severity to the currently low exploitation likelihood: low EPSS, not KEV-listed, no ransomware association, and no known mature exploit.