CVE-2026-43023: Linux Kernel Bluetooth Race Condition

CVE-2026-43023 Overview

CVE-2026-43023 is a race condition vulnerability in the Linux kernel's Bluetooth Synchronous Connection-Oriented (SCO) socket implementation. The flaw exists in sco_sock_connect(), which checks sk_state and sk_type without holding the socket lock. Two concurrent connect() syscalls on the same socket can both pass the state check and enter sco_connect(), leading to a use-after-free condition. The buggy scenario also produces a double sock_put() and leaks Host Controller Interface (HCI) connections. The vulnerability requires local access and low privileges to exploit.

Critical Impact
Local attackers with the ability to issue Bluetooth socket syscalls can trigger a use-after-free in kernel memory, potentially leading to privilege escalation or kernel memory corruption.

Affected Products

Linux kernel (Bluetooth SCO subsystem)
Distributions shipping affected upstream kernel versions
Systems with Bluetooth stack enabled and SCO socket support

Discovery Timeline

2026-05-01 - CVE-2026-43023 published to NVD
2026-05-03 - Last updated in NVD database

Technical Details for CVE-2026-43023

Vulnerability Analysis

The vulnerability is a [CWE-362] race condition in the Linux Bluetooth SCO socket layer. The function sco_sock_connect() validates sk_state and sk_type before acquiring the socket lock with lock_sock(). This unlocked validation window allows two threads issuing connect() on the same socket to both observe sk_state == BT_OPEN and proceed into sco_connect().

When an HCI disconnect runs between Thread A's successful connection and Thread B's blocked attempt, Thread B revives a BT_CLOSED and SOCK_ZAPPED socket back to BT_CONNECT. Subsequent cleanup triggers a double sock_put() and dereferences freed memory. The original connection (conn1) is also leaked because sco_conn_del() cleared the association before Thread B reattached the socket to a new connection (conn2).

Root Cause

The root cause is the absence of socket-level serialization during state validation in sco_sock_connect(). The state and type checks executed without lock_sock() allow concurrent connect operations to bypass mutual exclusion. An additional defect in the original code only assigned an error code for the sk_type != SOCK_SEQPACKET mismatch instead of returning it, allowing invalid state transitions to proceed.

Attack Vector

A local attacker with permission to create Bluetooth SCO sockets issues two concurrent connect() syscalls on the same socket file descriptor. By racing the connect attempts against an HCI disconnect event, the attacker forces the socket through the BT_OPEN → BT_CONNECT → BT_CLOSED → BT_CONNECT sequence described in the patch commit message. The resulting zombie socket state produces a use-after-free that an attacker can leverage for kernel memory corruption or privilege escalation.

No public exploit code is available. Refer to the upstream kernel commit dabf222 for the patch series and full technical context.

Detection Methods for CVE-2026-43023

Indicators of Compromise

Unexpected kernel oops or panic messages referencing sco_sock_connect, sco_connect, sco_chan_add, or sco_conn_del in dmesg and /var/log/kern.log
KASAN reports flagging use-after-free in the Bluetooth SCO code paths
Processes performing repeated rapid connect() calls on AF_BLUETOOTH sockets with BTPROTO_SCO
Anomalous Bluetooth HCI disconnect events correlated with userspace connect bursts

Detection Strategies

Enable Kernel Address Sanitizer (KASAN) on test systems to surface the use-after-free during fuzzing or workload replay
Monitor auditd for socket() and connect() syscalls with family=31 (AF_BLUETOOTH) and unusual rates per process
Inspect kernel ring buffer for warnings tied to sco_chan_add failures or sock reference count anomalies

Monitoring Recommendations

Track loaded kernel versions across the fleet and flag hosts running unpatched Bluetooth-enabled kernels
Alert on non-administrative users binding or connecting BTPROTO_SCO sockets in server environments where Bluetooth is not required
Forward kernel logs to a centralized analytics pipeline to correlate crash signatures with Bluetooth subsystem activity

How to Mitigate CVE-2026-43023

Immediate Actions Required

Apply the upstream kernel patches referenced in the stable tree commits or update to a distribution kernel that includes the fix
Disable the Bluetooth stack on systems that do not require it by unloading the bluetooth and bnep modules and blacklisting them in /etc/modprobe.d/
Restrict access to AF_BLUETOOTH sockets using seccomp filters or Linux capability constraints for untrusted workloads
Audit running processes for unnecessary Bluetooth privileges and remove CAP_NET_RAW/CAP_NET_ADMIN where not required

Patch Information

The fix is committed across multiple stable branches. Relevant commits include 7e296ff, 8a5b013, 98c8d3b, adb90cd, d002bd1, and dabf222. The patch moves lock_sock() ahead of the sk_state and sk_type checks in sco_sock_connect(), returns the error for sk_type != SOCK_SEQPACKET, re-checks the socket state inside sco_connect() after acquiring the lock, validates sco_pi(sk)->conn in sco_chan_add() to prevent double-attach, and calls hci_conn_drop() on sco_chan_add failure to prevent HCI connection leaks.

Workarounds

Blacklist the Bluetooth kernel modules on systems that do not need Bluetooth connectivity
Use systemctl disable --now bluetooth.service to stop the user-space Bluetooth daemon and reduce attack surface
Apply CONFIG_BT=n in custom kernel builds for hardened server deployments

bash

# Configuration example: disable Bluetooth modules to mitigate CVE-2026-43023
sudo systemctl disable --now bluetooth.service
echo 'install bluetooth /bin/false' | sudo tee /etc/modprobe.d/disable-bluetooth.conf
echo 'install btusb /bin/false'    | sudo tee -a /etc/modprobe.d/disable-bluetooth.conf
sudo rmmod bnep btusb bluetooth 2>/dev/null || true
uname -r   # verify running kernel includes the fix