CVE-2026-64471

What it actually does

This is a Linux kernel use-after-free/double-free condition in the Bluetooth USB driver error path. If btusb controller registration fails, sibling USB interfaces may not be released correctly; when the device is later disconnected, stale references can be freed or accessed again. The most likely impact is a kernel crash or system instability when a vulnerable Bluetooth USB device registration path is exercised, although use-after-free bugs in kernel context can sometimes become more severe if an attacker can reliably shape memory state.

Why it matters to the business

Systems using vulnerable Linux kernels with USB Bluetooth support may be exposed to local denial-of-service risk, especially where untrusted USB peripherals can be attached. The currently reported exploitation likelihood is low, it is not listed in CISA KEV, and no public exploit maturity is indicated, so remediation should be handled through normal kernel patch cycles unless affected systems allow broad physical or peripheral access.

How an attack unfolds

An attacker would need a way to trigger the vulnerable btusb probe and failure path, typically by attaching or emulating a USB Bluetooth device that causes controller registration to fail. The vulnerable kernel mishandles sibling interface cleanup after the failed registration. When the device is disconnected or the driver unwinds state, the same interface-related object can be accessed or freed after its lifetime has ended. In a straightforward attack this can panic or destabilize the kernel; a more advanced exploit would require precise control over USB behavior and kernel heap layout, and there is no current indication of mature public exploitation.

How to fix it

Update to a Linux kernel version that includes the upstream btusb fix for the registration-failure cleanup path. Where distribution packages are used, apply the vendor kernel security update rather than attempting to patch the driver manually. If immediate patching is not possible, reduce exposure by disabling unused Bluetooth support, blacklisting the btusb module where operationally acceptable, blocking untrusted USB peripherals, and restricting physical access to systems that load the btusb driver.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for this issue, not only that updated packages are installed on disk. Reboot after kernel updates where required. Verify whether the btusb module is present or loaded using standard module inventory commands, and confirm Bluetooth USB devices are not accepted on systems where Bluetooth is disabled as a mitigation. Review distribution advisories or kernel changelogs for the btusb registration-failure cleanup fix if exact fixed package versions are not available.

Typical attack path

1. Gain physical access to a target system or another mechanism to present a USB Bluetooth device to the host.
2. Attach or emulate a Bluetooth USB device that exercises the btusb driver probe path.
3. Cause Bluetooth controller registration to fail during device initialization.
4. Trigger disconnect or cleanup handling for the partially registered device.
5. Exploit the stale object reference, most likely causing a kernel crash or potentially attempting kernel memory corruption.

How to detect it

Look for evidence of attempted triggering through kernel logs, system journal, crash dumps, and endpoint telemetry around USB Bluetooth device insertion/removal. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, crash dump directories, kernel oops reports, KASAN reports, USB authorization logs, and EDR device-control events. Investigate sequences where a USB Bluetooth device is connected, Bluetooth HCI/controller registration fails, and the system logs a kernel oops, panic, use-after-free, double-free, or crash in btusb probe/disconnect routines. Because there are no known public exploit artifacts, detection should focus on behavioral evidence: unexpected btusb loading, repeated USB Bluetooth enumeration failures, abnormal disconnect events, and kernel memory-safety reports referencing btusb.

• BUG: KASAN: use-after-free
• BUG: KASAN: double-free
• general protection fault
• kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• btusb_probe
• btusb_disconnect
• btusb
• Bluetooth: hci
• usbcore: registered new interface driver btusb
• /var/log/kern.log
• /var/log/messages
• /var/crash/
• /sys/module/btusb

What your security team should do

• Prioritize patching Linux endpoints, kiosks, workstations, and appliances where users or attackers can attach USB peripherals.
• If Bluetooth is not required, disable Bluetooth services and blacklist the btusb kernel module as a compensating control.
• Enforce USB device control policies for shared, public, or physically exposed systems.
• Monitor for kernel crashes, KASAN reports, or oops traces involving btusb, Bluetooth HCI registration, or USB device disconnect handling.
• Track vendor kernel advisories for exact fixed package versions and ensure systems reboot into the fixed kernel after patch deployment.