CVE-2026-64557: Linux Kernel Bluetooth Use-After-Free

CVE-2026-64557 Overview

CVE-2026-64557 is a use-after-free vulnerability in the Linux kernel's Bluetooth Logical Link Control and Adaptation Protocol (L2CAP) subsystem. The flaw resides in l2cap_sock_new_connection_cb(), which returned l2cap_pi(sk)->chan after release_sock(parent). Once the parent lock is dropped, the newly enqueued child socket becomes reachable through the accept queue. Another task can accept and free the socket before the callback dereferences it, resulting in a use-after-free condition.

The vulnerability affects the Linux kernel Bluetooth stack and can be triggered by adjacent-network attackers within Bluetooth range.

Critical Impact
An adjacent attacker within Bluetooth range can trigger a use-after-free in kernel space, potentially leading to memory corruption, denial of service, or arbitrary kernel code execution.

Affected Products

Linux kernel (Bluetooth L2CAP subsystem)
Distributions and downstream kernels shipping the vulnerable l2cap_sock_new_connection_cb() implementation
Systems with Bluetooth enabled and reachable from adjacent devices

Discovery Timeline

2026-07-29 - CVE-2026-64557 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-64557

Vulnerability Analysis

The vulnerability lives in the L2CAP socket layer of the Linux Bluetooth stack. When a new L2CAP connection arrives, the kernel invokes l2cap_sock_new_connection_cb() to create a child socket for the incoming connection. The callback previously returned l2cap_pi(sk)->chan after calling release_sock(parent) on the parent socket lock.

Dropping the parent lock exposes the newly enqueued child socket through the accept queue. A concurrent task calling accept() can dequeue the child socket, close it, and free the associated l2cap_chan structure. When the original callback path subsequently dereferences the freed channel, the kernel operates on reclaimed memory. This condition maps to Use-After-Free [CWE-416] triggered by a race between the callback and the accept path.

Root Cause

The root cause is unclear ownership of the child channel's lifetime between the callback and the L2CAP core. The callback both allocated the channel and returned it after releasing the parent lock, creating a window where the channel could be freed by another task before the caller finished using the returned pointer. Configuration logic was also duplicated between l2cap_sock_init() and the various new_connection callbacks, increasing the surface for lifetime mistakes.

The fix reworks the ->new_connection() operation so the core, not the callback, owns the child channel's lifetime. The operation now receives a pre-allocated new_chan and returns an errno rather than allocating and returning a channel. l2cap_new_connection() allocates the child channel and links it into the conn list via __l2cap_chan_add() before invoking the callback, so the conn-list reference keeps the channel alive after release_sock(parent). Duplicated configuration is consolidated into l2cap_chan_set_defaults(), which inherits from the parent channel when supplied.

Attack Vector

Exploitation requires an attacker on an adjacent network, specifically Bluetooth range of the target device. The attacker initiates L2CAP connections against a listening socket while a local process races to accept and close the resulting child sockets. Successful exploitation triggers kernel memory corruption. See the upstream fixes for technical details: Kernel Git Commit 36da806, Kernel Git Commit 6fef032, Kernel Git Commit 733e76e, Kernel Git Commit 84e718b, Kernel Git Commit 8c37e43, and Kernel Git Commit b392980.

No public proof-of-concept exploit is available for this vulnerability at time of publication.

Detection Methods for CVE-2026-64557

Indicators of Compromise

Unexpected kernel oops, panics, or KASAN: use-after-free reports referencing l2cap_sock_new_connection_cb or l2cap_chan in kernel logs.
Repeated Bluetooth L2CAP connection attempts from unknown adjacent devices followed by kernel instability.
Crashes in Bluetooth-related workloads correlated with concurrent accept() activity on L2CAP sockets.

Detection Strategies

Enable KASAN on test and pre-production kernels to surface use-after-free access patterns in the L2CAP path.
Monitor dmesg and journal logs for stack traces containing l2cap_sock, l2cap_chan, or hci symbols.
Inventory hosts running kernel versions predating the referenced upstream commits and prioritize them for patching.

Monitoring Recommendations

Alert on kernel panic and oops events from endpoints with active Bluetooth interfaces.
Track Bluetooth pairing and L2CAP connection telemetry from Linux endpoints, especially servers or workstations where Bluetooth is not required.
Correlate crash telemetry with proximity events such as new Bluetooth device discovery bursts.

How to Mitigate CVE-2026-64557

Immediate Actions Required

Apply the upstream Linux kernel patches that rework ->new_connection() ownership and consolidate defaults into l2cap_chan_set_defaults().
Update to distribution kernels that include the fix commits referenced in the NVD entry.
Disable the Bluetooth stack on systems that do not require it by unloading bluetooth and btusb modules or masking the bluetooth.service unit.

Patch Information

The fix is available in the mainline and stable Linux kernel trees through the following commits: 36da806f7fbaee56ad9e81859deec203f9728700, 6fef032af0092ed5ccb767239a9ac1bc38c08a40, 733e76e74e406c1d1ddc7369420dd8a47f48bb8a, 84e718b6a814edc84159361f9f454a4e92ae91ae, 8c37e4338c801ebb8cee52436c01c41e009f6e87, and b39298044e5534612511a2ff5de03ba5f6e7a820. Rebuild custom kernels against these commits or install vendor-provided updates as soon as they are released.

Workarounds

Turn Bluetooth radios off on devices where the feature is not operationally required.
Blocklist the bluetooth, btusb, and related kernel modules on servers to prevent load at boot.
Restrict physical and RF proximity to sensitive Linux devices to reduce the adjacent-network attack surface.

bash

# Configuration example: disable Bluetooth on Linux hosts that do not require it
sudo systemctl disable --now bluetooth.service
echo "install bluetooth /bin/true" | sudo tee /etc/modprobe.d/disable-bluetooth.conf
echo "install btusb /bin/true" | sudo tee -a /etc/modprobe.d/disable-bluetooth.conf
sudo rmmod btusb bluetooth 2>/dev/null || true