CVE-2026-52918: Linux Kernel Bluetooth Race Condition

CVE-2026-52918 Overview

CVE-2026-52918 is a race condition vulnerability in the Linux kernel's Bluetooth subsystem. The flaw resides in bt_sock_poll(), which walks the accept_q accept queue without synchronization. Concurrently, child socket teardown can unlink the same socket and drop its last reference, creating a use-after-free condition. According to the upstream commit description, the unsynchronized accept queue walk has existed since the initial Bluetooth import into the Linux kernel. The fix introduces a dedicated lock to serialize accept_q access and reworks bt_accept_dequeue() to acquire temporary child references under the queue lock before releasing it and locking the child socket.

Critical Impact
Concurrent access to the Bluetooth accept queue without proper synchronization can lead to use-after-free conditions, potentially resulting in kernel memory corruption or denial of service on systems with active Bluetooth connections.

Affected Products

Linux kernel — Bluetooth subsystem
Distributions packaging affected Linux kernel versions prior to the patched stable releases
Systems with Bluetooth enabled and accepting inbound connections (L2CAP, RFCOMM, SCO)

Discovery Timeline

2026-06-24 - CVE CVE-2026-52918 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-52918

Vulnerability Analysis

The vulnerability is a race condition [CWE-362] in the Linux Bluetooth socket layer. The function bt_sock_poll() iterates the per-socket accept_q list to determine pollable readiness for listening Bluetooth sockets. This iteration occurs without holding any lock that protects the accept queue.

In parallel, a child socket on the same accept_q may be undergoing teardown. The teardown path unlinks the child from the parent's queue and drops the final reference on the child socket. If bt_sock_poll() dereferences the child entry concurrently, it can touch freed memory.

The defect predates modern kernel locking conventions and has been present since the Bluetooth stack was initially imported. Exploitation requires local interaction with the Bluetooth socket interface, making this primarily a local denial-of-service or memory corruption issue rather than a remote attack.

Root Cause

The accept queue (accept_q) is a linked list of pending child sockets attached to a listening parent. Reads from bt_sock_poll() and writes from bt_accept_unlink() during child teardown are not serialized by a common lock. The parent socket lock is not consistently held across both paths, allowing the poll path to observe a partially modified list or follow a pointer to a freed struct sock.

Attack Vector

A local user with permission to open Bluetooth sockets can trigger the race by issuing concurrent poll() or select() calls on a listening Bluetooth socket while child connections are being torn down. Reliable triggering requires precise timing between the poll iteration and reference drop, but kernel fuzzers and stress workloads can reach the window.

No verified proof-of-concept exploit is publicly available for CVE-2026-52918. The vulnerability mechanism is documented in the upstream patch series referenced by commits 41c8c1c, 4ec1778, 85f8674, 8b4c412, a218bf6, be43e6b, d9ce4de, and e83f5e2.

Detection Methods for CVE-2026-52918

Indicators of Compromise

Kernel oops or panic messages referencing bt_sock_poll, bt_accept_dequeue, or accept_q in dmesg or /var/log/kern.log
KASAN use-after-free reports involving Bluetooth socket structures on instrumented kernels
Unexpected reboots or kernel stalls on hosts with active Bluetooth services under concurrent socket workloads

Detection Strategies

Inventory running kernel versions across Linux endpoints and compare against patched stable releases referenced in the upstream commits
Audit for the presence of the Bluetooth kernel modules (bluetooth, bnep, rfcomm, l2cap) on systems that do not require them
Review crash dumps and kdump artifacts for stack traces touching the Bluetooth socket layer

Monitoring Recommendations

Forward kernel logs to a centralized logging or SIEM platform and alert on panics, oopses, and KASAN reports referencing Bluetooth symbols
Monitor process and module load activity for unexpected use of Bluetooth interfaces on servers or workstations where Bluetooth is not required
Track patch deployment status for the affected kernel packages across the fleet

How to Mitigate CVE-2026-52918

Immediate Actions Required

Apply vendor-supplied kernel updates that incorporate the upstream fix introducing the dedicated accept_q lock
On systems that do not need Bluetooth, unload the bluetooth module and blacklist it to remove the attack surface entirely
Restrict local access on multi-user systems and enforce least privilege for accounts able to open Bluetooth sockets

Patch Information

The fix is delivered through the following upstream Linux kernel commits, which protect accept_q with a dedicated lock and rework bt_accept_dequeue() to take temporary child references under the queue lock:

Consume the fix through the stable kernel update provided by your Linux distribution.

Workarounds

Disable the Bluetooth subsystem on hosts that do not require it by blacklisting the kernel module and stopping the bluetooth.service daemon
Limit local user accounts and container workloads from interacting with Bluetooth sockets through seccomp, AppArmor, or SELinux policy
Reduce concurrent workloads that issue poll()/select() against listening Bluetooth sockets until the patched kernel is deployed

bash

# Disable and blacklist the Bluetooth kernel module
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 bnep rfcomm bluetooth btusb 2>/dev/null || true

# Verify the running kernel version after patching
uname -r