KernelScan.io

HIGH

bluetooth SCO Socket Race

CVE-2026-43023

CVSS 7.8 / 10.0 NVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

KernelScan AI7.8HIGH

01

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: fix race conditions in sco_sock_connect() sco_sock_connect() checks sk_state and sk_type without holding the socket lock. Two concurrent connect() syscalls on the same socket can both pass the check and enter sco_connect(), leading to use-after-free. The buggy scenario involves three participants and was confirmed with additional logging instrumentation: Thread A (connect): HCI disconnect: Thread B (connect): sco_sock_connect(sk) sco_sock_connect(sk) sk_state==BT_OPEN sk_state==BT_OPEN (pass, no lock) (pass, no lock) sco_connect(sk): sco_connect(sk): hci_dev_lock hci_dev_lock hci_connect_sco <- blocked -> hcon1 sco_conn_add->conn1 lock_sock(sk) sco_chan_add: conn1->sk = sk sk->conn = conn1 sk_state=BT_CONNECT release_sock hci_dev_unlock hci_dev_lock sco_conn_del: lock_sock(sk) sco_chan_del: sk->conn=NULL conn1->sk=NULL sk_state= BT_CLOSED SOCK_ZAPPED release_sock hci_dev_unlock (unblocked) hci_connect_sco -> hcon2 sco_conn_add -> conn2 lock_sock(sk) sco_chan_add: sk->conn=conn2 sk_state= BT_CONNECT // zombie sk! release_sock hci_dev_unlock Thread B revives a BT_CLOSED + SOCK_ZAPPED socket back to BT_CONNECT. Subsequent cleanup triggers double sock_put() and use-after-free. Meanwhile conn1 is leaked as it was orphaned when sco_conn_del() cleared the association. Fix this by: - Moving lock_sock() before the sk_state/sk_type checks in sco_sock_connect() to serialize concurrent connect attempts - Fixing the sk_type != SOCK_SEQPACKET check to actually return the error instead of just assigning it - Adding a state re-check in sco_connect() after lock_sock() to catch state changes during the window between the locks - Adding sco_pi(sk)->conn check in sco_chan_add() to prevent double-attach of a socket to multiple connections - Adding hci_conn_drop() on sco_chan_add failure to prevent HCI connection leaks

02

Engine v0.2.0

Risk summary

This race condition in Bluetooth SCO socket handling can lead to use-after-free vulnerabilities when multiple threads attempt to connect the same socket concurrently. An attacker with local access and the ability to create Bluetooth sockets could potentially trigger memory corruption, leading to system crashes or possible privilege escalation. The vulnerability is particularly concerning in multi-threaded applications that handle Bluetooth connections.

Affectednet/bluetooth/sco.c

Vulnerability analysis

Root Cause: The sco_sock_connect() function checks socket state (sk_state) and socket type (sk_type) without holding the socket lock, creating a race condition window. Two concurrent connect() syscalls on the same socket can both pass these unlocked checks and proceed to sco_connect(), leading to inconsistent socket state transitions and use-after-free conditions.

Attack Surface: Local attack surface requiring the ability to create Bluetooth SCO sockets and make concurrent connect() syscalls. The vulnerability is triggered through the Bluetooth subsystem when multiple threads attempt to connect the same socket simultaneously, particularly during HCI disconnect events that can create timing windows for the race condition.

Fix Mechanism: The patch implements multiple synchronization improvements: (1) moves lock_sock() before state/type checks in sco_sock_connect() to serialize concurrent connect attempts, (2) adds state re-validation in sco_connect() after acquiring the socket lock to catch state changes during the lock acquisition window, (3) adds connection validation in sco_chan_add() to prevent double-attachment, (4) fixes error handling to properly return errors instead of just assigning them, and (5) adds proper cleanup with hci_conn_drop() on failures to prevent resource leaks.

03

BranchFixed inPatch commit
6.16.1.168dabf22269242
6.126.12.817e296ffdab5b
6.186.18.2298c8d3bfdaa6
6.196.19.12d002bd11024b
6.66.6.134adb90cd0f9f7
mainline7.08a5b0135d4a5