CVE-2026-64406: Linux Kernel Bluetooth UAF Vulnerability

CVE-2026-64406 Overview

CVE-2026-64406 is a use-after-free (UAF) vulnerability in the Linux kernel Bluetooth subsystem. The flaw resides in bt_accept_dequeue() and involves incorrect reference counting when handling sockets on the accept queue. KASAN observed the condition during listening L2CAP socket cleanup, where sock_hold() accessed freed memory after the last queue reference was dropped.

An attacker within Bluetooth range can trigger the race condition to corrupt kernel memory. Successful exploitation may lead to denial of service or kernel-level code execution.

Critical Impact
A use-after-free in the L2CAP accept path allows an adjacent-network attacker to corrupt kernel memory, with potential for privilege escalation or kernel code execution on affected Linux systems.

Affected Products

Linux kernel Bluetooth subsystem (L2CAP accept queue handling)
Multiple stable branches - refer to the kernel.org commit references
Distributions shipping vulnerable kernels prior to backported fixes

Discovery Timeline

2026-07-25 - CVE-2026-64406 published to NVD
2026-07-27 - Last updated in NVD database

Technical Details for CVE-2026-64406

Vulnerability Analysis

The vulnerability is a use-after-free [CWE-416] in the Linux kernel Bluetooth stack, specifically in bt_accept_dequeue(). The function manages sockets waiting to be accepted on a Bluetooth listening socket, such as an L2CAP server socket.

bt_accept_get() acquires a temporary reference on a socket before releasing the accept queue lock. This temporary reference is intended to keep the socket alive while the caller operates on it outside the lock. In the buggy code path, bt_accept_dequeue() released this temporary reference before invoking bt_accept_unlink().

bt_accept_unlink() then drops the queue reference. If the queue reference was the final one, the socket memory is freed. The subsequent sock_hold() call touches the freed struct sock, producing a KASAN use-after-free report during listening L2CAP socket teardown.

Root Cause

The root cause is incorrect reference-count ordering between the queue-walk temporary reference and the queue reference held on the accept list. Dropping the temporary reference too early leaves only the queue reference, which bt_accept_unlink() then removes. Any subsequent access to the socket, including sock_hold(), occurs on freed memory.

The fix retains the temporary queue-walk reference through the unlink operation and transfers it to the caller on success. On the closed and not-yet-connected paths, the reference is dropped explicitly to avoid leaks.

Attack Vector

Exploitation requires proximity within Bluetooth range and the ability to interact with a listening L2CAP socket on the target system. The attacker must trigger connection events that race with socket cleanup on the accept queue. Because the vulnerable code runs in kernel context, a successful UAF can be leveraged for kernel memory corruption.

The vulnerability manifests during listening L2CAP socket cleanup as observed by KASAN. Refer to the kernel.org stable commit for the reference-counting fix.

Detection Methods for CVE-2026-64406

Indicators of Compromise

KASAN reports referencing bt_accept_dequeue, bt_accept_unlink, or sock_hold in kernel logs
Kernel oops or panic messages originating from the Bluetooth L2CAP subsystem during socket teardown
Unexpected termination of bluetoothd or processes holding L2CAP listening sockets
Anomalous Bluetooth connection or disconnection bursts targeting hosts with L2CAP servers

Detection Strategies

Enable KASAN in test and staging kernels to surface use-after-free conditions in the Bluetooth stack
Monitor dmesg and journalctl -k for BUG: KASAN: use-after-free entries referencing Bluetooth symbols
Alert on unexpected kernel crashes on endpoints with Bluetooth enabled, especially servers and IoT gateways
Correlate Bluetooth pairing and connection telemetry with host stability events

Monitoring Recommendations

Ingest kernel logs into a centralized SIEM and create rules for Bluetooth subsystem crashes
Track kernel versions across the fleet and flag hosts running versions predating the stable backports
Monitor Bluetooth interface state changes and connection rates on endpoints not expected to use Bluetooth

How to Mitigate CVE-2026-64406

Immediate Actions Required

Apply the kernel updates from your Linux distribution as soon as backports are available
Inventory systems with Bluetooth hardware enabled and prioritize patching endpoints exposing L2CAP listeners
Disable the Bluetooth stack on hosts that do not require it, particularly servers and infrastructure devices
Restrict physical and radio-frequency proximity to sensitive systems until patches are deployed

Patch Information

The Linux kernel maintainers released fixes across multiple stable branches. The patches retain the temporary queue-walk reference through bt_accept_unlink() and drop it explicitly on the closed and not-yet-connected paths. Reference commits include 0a98ff4e7b86, 26168db1ce5a, 4bd0b274054f, 50c662bdcd51, 6303ed4bbe00, 96ad400d5132, c0577c55219b, and c66a95e60b65.

Workarounds

Unload the bluetooth and btusb kernel modules on systems that do not need Bluetooth connectivity
Blacklist Bluetooth modules in /etc/modprobe.d/ to prevent load at boot
Stop and disable bluetooth.service via systemctl where the stack is not required
Physically disable Bluetooth radios in firmware or BIOS on servers and workstations that do not use Bluetooth

bash

# Disable and blacklist the Bluetooth stack on Linux
sudo systemctl stop bluetooth.service
sudo systemctl disable bluetooth.service

# Prevent modules from loading at boot
echo 'blacklist bluetooth' | sudo tee /etc/modprobe.d/blacklist-bluetooth.conf
echo 'blacklist btusb' | sudo tee -a /etc/modprobe.d/blacklist-bluetooth.conf

# Unload currently loaded modules
sudo modprobe -r btusb
sudo modprobe -r bluetooth