CVE-2026-64434: Linux Kernel Use-After-Free Vulnerability

CVE-2026-64434 Overview

CVE-2026-64434 is a use-after-free vulnerability in the Linux kernel's Bluetooth L2CAP (Logical Link Control and Adaptation Protocol) implementation. The flaw resides in l2cap_chan_timeout() within net/bluetooth/l2cap_core.c, which runs asynchronously and accesses chan->conn. When a Bluetooth connection is torn down while the channel timer is still running or pending, chan->conn can be freed. The timer worker then dereferences the freed l2cap_conn structure when attempting to acquire conn->lock, triggering a slab-use-after-free condition detected by KASAN.

Critical Impact
An attacker within Bluetooth range can trigger memory corruption in the kernel by racing L2CAP channel setup and teardown, potentially resulting in denial of service or arbitrary kernel memory manipulation.

Affected Products

Linux kernel Bluetooth subsystem (net/bluetooth/l2cap_core.c)
Distributions shipping affected upstream kernel versions prior to the fix commits
Systems with Bluetooth enabled and reachable via HCI (including virtual HCI via hci_vhci)

Discovery Timeline

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

Technical Details for CVE-2026-64434

Vulnerability Analysis

The vulnerability is a use-after-free in the L2CAP channel timeout worker. When l2cap_conn_add() allocates an l2cap_conn structure and a channel is attached to it, the channel stores a raw pointer to conn in chan->conn without incrementing a reference count. If the underlying HCI device is closed (for example through hci_dev_close_sync() or vhci_release()), hci_conn_hash_flush() calls hci_disconn_cfm(), which frees the l2cap_conn from the kmalloc-512 cache.

Any pending l2cap_chan_timeout work scheduled on the events workqueue continues to run. The worker calls mutex_lock(&conn->lock) on memory that has already been released, producing the KASAN slab-use-after-free reported at l2cap_chan_timeout+0x5d/0x1b0. Successful exploitation can corrupt kernel memory or leak sensitive kernel state.

Root Cause

The root cause is missing reference counting between an L2CAP channel and its parent connection. chan->conn was assigned without calling l2cap_conn_get(), so the channel had no ownership guarantee over the l2cap_conn object. The connection lifetime was driven exclusively by HCI teardown, which could race with the asynchronous timer worker. This is a classic Use-After-Free [CWE-416] caused by asymmetric object lifetimes between two concurrent kernel contexts.

Attack Vector

Exploitation requires proximity to the target radio (Adjacent Network attack vector). An attacker interacting with the Bluetooth stack can initiate an L2CAP channel setup that arms chan->timer, then trigger a rapid disconnect or force the HCI device to be closed before the timer fires. The freed l2cap_conn slab may be reallocated by an attacker-controlled object before the timer worker executes mutex_lock(), enabling controlled write primitives inside the kernel slab allocator.

The upstream fix takes a reference to l2cap_conn via l2cap_conn_get() when the channel is added, releases it in the channel destructor, and introduces a new FLAG_DEL channel flag to coordinate teardown. This ensures the l2cap_conn remains alive as long as any channel references it.

Detection Methods for CVE-2026-64434

Indicators of Compromise

KASAN reports referencing l2cap_chan_timeout and mutex_lock in kernel logs
Kernel panics or BUG: messages originating from net/bluetooth/l2cap_core.c
Unexpected kworker crashes tied to the events workqueue processing L2CAP work items
Abnormal Bluetooth HCI device open/close sequences from unprivileged processes

Detection Strategies

Enable KASAN on test and pre-production kernels to surface use-after-free access patterns in the L2CAP path
Monitor dmesg and journald for slab-use-after-free entries referencing l2cap_ symbols
Baseline Bluetooth workqueue activity and alert on rapid connect/disconnect cycles that could indicate race exploitation attempts

Monitoring Recommendations

Ingest kernel logs into a centralized log platform and alert on KASAN, BUG:, and l2cap_chan_timeout strings
Track loaded kernel version across the fleet and flag hosts running unpatched Bluetooth-enabled kernels
On servers and virtual machines that do not require Bluetooth, alert when the bluetooth or btusb modules are loaded

How to Mitigate CVE-2026-64434

Immediate Actions Required

Apply the upstream Linux kernel patches referenced by commits 0b0e2bf, 50c38d9f, 91047a4, b66774b, and d3b739d from git.kernel.org stable
Track distribution advisories from your Linux vendor and deploy fixed kernel packages during the next maintenance window
On systems that do not require Bluetooth, disable and blacklist the Bluetooth kernel modules to remove the attack surface

Patch Information

The fix modifies net/bluetooth/l2cap_core.c so that chan->conn holds a reference to l2cap_conn via l2cap_conn_get() when the channel is attached, and releases it in the channel destructor. A new FLAG_DEL flag prevents further use of a channel that is being destroyed. Reference commits: 0b0e2bf, 50c38d9f, 91047a4, b66774b, and d3b739d.

Workarounds

Unload the Bluetooth stack on hosts that do not need it using modprobe -r bluetooth btusb and add a blacklist entry in /etc/modprobe.d/
Disable Bluetooth radios in firmware or BIOS on servers where the hardware is present but unused
Restrict physical and RF proximity to sensitive systems until patched kernels are deployed

bash

# Disable and blacklist Bluetooth kernel modules on Linux hosts that do not require Bluetooth
sudo systemctl disable --now bluetooth.service
sudo modprobe -r btusb bluetooth

cat <<EOF | sudo tee /etc/modprobe.d/disable-bluetooth.conf
blacklist bluetooth
blacklist btusb
install bluetooth /bin/true
install btusb /bin/true
EOF

sudo update-initramfs -u