High 7.8Published May 1, 2026

CVE-2026-43023Bluetooth: SCO: fix race conditions in sco_sock_connect()

Updated under an hour ago (2026-10-19 08:30 UTC)

Does this affect you?

It affects Linux and 1 other product. Add what you run to find out whether that includes you.

No exploitation reported and no EPSS estimate yet.

Do this next

Start free and add your stack

Free account, 1 product

Every CVE for Linux

Exploited in the last 30 days

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

CVSS: 7.8 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weakness (CWE): Not given
Known exploited: Not in CISA's KEV catalog
EPSS (exploitation in the next 30 days): Not loaded for this CVE
Assigned by: Linux
NVD analysis: Analyzed
Record last updated: Oct 16, 2026
First seen by InfoSec Signals: Oct 9, 2026

Affected products

Affected products

Linux Linux linux:linux (from the name)	from 70a13b1e25fef37c87c8a1228ddb8900efbca7cf before dabf22269242e2f2bf44c43fcdc2fa763df7f9cc; from 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 before adb90cd0f9f7a8d438fcb93354040fbafc5ae2a0; 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 builds before 7e296ffdab5bdab718dff7c14288fdcb9154fa27; from 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 before 98c8d3bfdaa657d8f472dbbebd7ea8cd816d8a8d; from 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 before d002bd11024bd231bcb606877e33951ffb7bed14; 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 builds before 8a5b0135d4a5d9683203a3d9a12a711ccec5936b; from 6.1.109 before 6.1.168	CNA record
linux linux_kernel linux:linux_kernel	from 6.1.109 before 6.1.168; from 6.3.1 before 6.6.134; from 6.7 before 6.12.81; from 6.13 before 6.18.22; from 6.19 before 6.19.12; 6.3; 6.3; 7.0; and 5 more ranges	NVD

References

https://git.kernel.org/stable/c/dabf22269242e2f2bf44c43fcdc2fa763df7f9ccpatch
https://git.kernel.org/stable/c/adb90cd0f9f7a8d438fcb93354040fbafc5ae2a0patch
https://git.kernel.org/stable/c/7e296ffdab5bdab718dff7c14288fdcb9154fa27patch
https://git.kernel.org/stable/c/98c8d3bfdaa657d8f472dbbebd7ea8cd816d8a8dpatch
https://git.kernel.org/stable/c/d002bd11024bd231bcb606877e33951ffb7bed14patch
https://git.kernel.org/stable/c/8a5b0135d4a5d9683203a3d9a12a711ccec5936bpatch

The CVE record on cve.org NVD's entry

The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.