CVE-2026-64206: Linux Kernel Bluetooth Race Condition

CVE-2026-64206 Overview

CVE-2026-64206 is a deadlock vulnerability in the Linux kernel's Bluetooth Logical Link Control and Adaptation Protocol (L2CAP) subsystem. The flaw occurs in l2cap_conn_del(), which acquires conn->lock and then calls cancel_work_sync() for pending_rx_work. The worker function process_pending_rx() acquires the same mutex, creating a circular locking dependency during connection teardown. A Bluetooth connection tear-down racing with pending receive work can hang the kernel thread performing the cleanup, leading to denial of service on affected systems.

Critical Impact
A local or proximate attacker able to trigger L2CAP connection teardown while receive work is pending can cause a kernel deadlock, resulting in denial of service.

Affected Products

Linux kernel Bluetooth subsystem (L2CAP)
Kernel branches prior to the fix commits 2641a9e, d5616be, and e96fbac
Distributions shipping vulnerable kernel versions with Bluetooth enabled

Discovery Timeline

2026-07-20 - CVE-2026-64206 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-64206

Vulnerability Analysis

The vulnerability is a classic ABBA lock-ordering violation between a teardown path and a worker it attempts to flush. In l2cap_conn_del(), the kernel acquires conn->lock and subsequently calls cancel_work_sync(&conn->pending_rx_work). The cancel_work_sync() primitive blocks until any currently executing instance of the target work item completes. However, process_pending_rx() itself calls mutex_lock(&conn->lock) as part of processing queued receive frames. If process_pending_rx() is already running when teardown begins, it will block waiting for conn->lock, while the teardown thread blocks inside cancel_work_sync() waiting for the worker to finish. Neither thread can proceed, producing a hard deadlock. Lockdep flags the condition as a possible circular locking dependency involving process_pending_rx+0x21/0x2a and l2cap_conn_del.constprop.0+0x3f/0x4e.

Root Cause

The root cause is inconsistent lock ordering in the L2CAP teardown path. Two delayed works handled in the same teardown were already cancelled before conn->lock was acquired, but pending_rx_work was cancelled after acquiring the mutex. This asymmetry broke the lock-before-drain invariant assumed elsewhere in the subsystem.

Attack Vector

The deadlock is reachable through normal Bluetooth L2CAP connection lifecycle events. An attacker able to establish an L2CAP connection and induce teardown while receive frames are queued to pending_rx_work can trigger the condition. Exploitation results in an unresponsive kernel worker thread rather than memory corruption or privilege escalation.

No verified public proof-of-concept code is available. The reporter noted a grounded PoC that preserved the l2cap_conn_ready() -> queue_work(..., &conn->pending_rx_work) submit path together with the vulnerable teardown ordering to reproduce the lockdep warning. Refer to the upstream commits for the exact code paths involved.

Detection Methods for CVE-2026-64206

Indicators of Compromise

Kernel log entries containing WARNING: possible circular locking dependency detected referencing process_pending_rx and l2cap_conn_del
Hung task warnings implicating kernel workers blocked on conn->lock during Bluetooth disconnection
Systems requiring reboot to recover Bluetooth functionality after abnormal connection termination

Detection Strategies

Enable CONFIG_PROVE_LOCKING (lockdep) in test kernels to surface the circular dependency during Bluetooth stress testing
Monitor dmesg and journalctl -k for INFO: task ... blocked for more than messages naming Bluetooth workqueues
Correlate kernel version inventory against the fixed commits 2641a9e0a1dd, d5616beb3355, and e96fbac8d3a7 to identify unpatched hosts

Monitoring Recommendations

Alert on repeated Bluetooth service restarts or kernel worker hangs on endpoints and IoT gateways
Track soft lockup and RCU stall events on systems with active Bluetooth radios
Include kernel package versions in configuration management data collection to accelerate patch verification

How to Mitigate CVE-2026-64206

Immediate Actions Required

Apply the upstream Linux kernel patches referenced by commits 2641a9e0a1dd, d5616beb3355, and e96fbac8d3a7
Update to a distribution kernel package that incorporates the L2CAP teardown fix
On systems that do not require Bluetooth, unload the bluetooth and btusb kernel modules and blacklist them

Patch Information

The fix reorders the teardown sequence so that cancel_work_sync(&conn->pending_rx_work) is called before conn->lock is acquired, matching the lock-before-drain ordering already used for the two delayed works in the same teardown path. The pending_rx queue is still purged after the work has been cancelled and conn->lock has been taken. Patch references: Kernel commit 2641a9e, Kernel commit d5616be, and Kernel commit e96fbac.

Workarounds

Disable Bluetooth at the firmware or hardware level on systems where it is not required
Prevent the bluetooth module from loading by adding it to /etc/modprobe.d/ blacklists
Restrict physical and radio proximity access to systems that must run Bluetooth until kernels are patched

bash

# Configuration example: disable and blacklist the Bluetooth stack
sudo systemctl stop bluetooth.service
sudo systemctl disable bluetooth.service
echo 'blacklist bluetooth' | sudo tee /etc/modprobe.d/blacklist-bluetooth.conf
echo 'blacklist btusb' | sudo tee -a /etc/modprobe.d/blacklist-bluetooth.conf
sudo modprobe -r btusb bluetooth 2>/dev/null || true
# Verify current kernel version against fixed commits
uname -r