CVE-2026-64470

What it actually does

This is a use-after-free flaw in the Linux kernel btusb Bluetooth driver during Marvell USB Bluetooth device probing. If Marvell out-of-band wakeup configuration submits transmit USB request blocks and a later probe error path frees associated driver state without first stopping those URBs, a completion callback can run after the memory has been released. The most likely outcome is a kernel crash or instability, but kernel use-after-free conditions can sometimes be shaped into memory corruption and potential local privilege escalation depending on timing, hardware behavior, allocator state, and enabled hardening features.

Why it matters to the business

Systems using affected Linux kernels with vulnerable Marvell USB Bluetooth hardware or exposed USB attachment paths may be susceptible to denial of service through kernel crashes, and in a worst case could face host compromise from a local attacker with the ability to attach or emulate a malicious Bluetooth USB device. The current public exploitation signal is low: EPSS is low, it is not listed in CISA KEV, ransomware use is not reported, and no mature public exploit is indicated. Operational priority is highest for laptops, kiosks, workstations, embedded Linux devices, and servers where untrusted USB devices can be attached.

How an attack unfolds

An attacker needs a path to influence btusb probe behavior, most plausibly by attaching, emulating, or compromising a Marvell USB Bluetooth device. During device initialization, the driver performs Marvell-specific wakeup configuration and may submit transmit URBs. The attacker then causes or triggers a later probe failure while those URBs remain outstanding. Because the vulnerable error path frees driver state without canceling the submitted URBs, a subsequent URB completion callback can dereference freed memory. In practical terms this may crash the kernel; with precise timing and control over memory reuse, an advanced attacker may attempt to turn the condition into kernel memory corruption and privilege escalation. This is not a typical network-reachable Bluetooth pairing attack; the meaningful exposure is local or physical USB/peripheral access to a Linux system using the affected driver path.

How to fix it

Apply the vendor-provided Linux kernel update that includes the btusb fix ensuring TX URBs are stopped on Marvell probe failure paths. Because no fixed package versions were provided in the input, use the latest stable kernel from the operating system or device vendor and verify that the vendor advisory for this issue is included. Where immediate patching is not possible, reduce exposure by disabling unused Bluetooth support, blocking the btusb module where operationally acceptable, restricting physical USB access, enforcing USB device control policies, and preventing untrusted users from attaching USB or emulated Bluetooth devices. Possible temporary mitigations include unloading or blacklisting the btusb module, disabling Bluetooth in firmware/BIOS or OS configuration, and using endpoint controls to allow only approved USB devices.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package is at or above the vendor-fixed release and that the kernel changelog or source includes the btusb change to stop TX URBs on Marvell probe failure. Validate exposure by checking whether Bluetooth USB support is enabled, whether the btusb module is loaded, and whether Marvell Bluetooth USB devices are present. Useful checks include reviewing `uname -a`, distribution package metadata, `modinfo btusb`, `lsmod | grep btusb`, `lsusb`, and kernel logs for btusb/Marvell probe activity. If Bluetooth is not required, confirm that the btusb module cannot be loaded and that Bluetooth adapters are not enumerating after reboot.

Typical attack path

1. Identify a Linux system using an affected kernel with btusb support and Marvell USB Bluetooth device handling enabled.
2. Gain local physical access, USB attachment capability, or control of a USB-emulated Bluetooth peripheral.
3. Present a crafted or misbehaving Marvell-compatible USB Bluetooth device to trigger the btusb probe path.
4. Cause Marvell out-of-band wakeup configuration to submit transmit URBs during probing.
5. Force a later probe failure before outstanding URBs are canceled.
6. Wait for a URB completion callback to run after associated driver memory has been freed.
7. Use the resulting use-after-free to crash the kernel or attempt controlled kernel memory corruption.

How to detect it

Look for evidence of suspicious Bluetooth USB device attachment followed by btusb probe failures, kernel memory errors, kernel oops/panic events, or unexpected reboots. Relevant log sources include `dmesg`, journald/kernel logs, `/var/log/kern.log`, `/var/log/messages`, crash dump facilities such as kdump/vmcore, endpoint USB device-control logs, and EDR telemetry for newly attached USB devices. Search for btusb and Marvell initialization messages occurring immediately before KASAN use-after-free reports, general protection faults, NULL pointer dereferences, kernel panics, or watchdog-triggered reboots. Because exploitation depends on a race/error path and may leave only crash artifacts, absence of a clean application-layer IOC does not rule out attempted exploitation. Correlate suspicious events with physical access records, USB VID/PID inventory changes, and any unexpected Bluetooth adapter enumeration.

• btusb
• Marvell
• Bluetooth: btusb
• use-after-free
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• kernel BUG
• Oops:
• general protection fault
• Unable to handle kernel paging request
• Kernel panic - not syncing
• usbcore: registered new interface driver btusb
• btusb_probe
• btusb_send_frame
• btusb_intr_complete
• btusb_tx_complete
• /var/log/kern.log
• /var/log/messages
• /var/crash/
• /proc/modules

What your security team should do

• Prioritize patching Linux endpoints and embedded systems that allow local USB access or use Marvell USB Bluetooth adapters.
• Inventory systems with the `btusb` module loaded or Bluetooth enabled, especially laptops, kiosks, shared workstations, and edge/IoT devices.
• Apply the latest vendor kernel updates and track distribution advisories for the exact fixed kernel versions.
• If patching is delayed, disable Bluetooth or blacklist `btusb` on systems where Bluetooth is not business-critical.
• Restrict untrusted USB device attachment using physical controls, USB allowlisting, endpoint device control, or kiosk lockdown policies.
• Review recent kernel logs for btusb probe failures, Marvell Bluetooth initialization errors, kernel oops events, KASAN use-after-free reports, or unexplained reboots following USB Bluetooth attachment.
• Treat repeated kernel crashes associated with Bluetooth USB probe activity as suspicious and preserve kernel logs, crash dumps, and attached-device metadata for investigation.