CVE-2026-43023
Awaiting Analysis Awaiting Analysis - Queue
Race Condition in Linux Kernel Bluetooth SCO Connection Handling

Publication date: 2026-05-01

Last updated on: 2026-05-03

Assigner: kernel.org

Description
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 Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-01
Last Modified
2026-05-03
Generated
2026-05-06
AI Q&A
2026-05-01
EPSS Evaluated
2026-05-05
NVD
CVE-2026-43023
EUVD
EUVD-2026-26622
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's Bluetooth SCO (Synchronous Connection-Oriented) socket connection function, specifically in sco_sock_connect(). The function checks the socket's state and type without holding the socket lock, which allows two concurrent connect() system calls on the same socket to both pass the checks and proceed simultaneously. This leads to a use-after-free condition because one thread can free or modify the socket while the other thread still uses it.

The issue arises when two threads (Thread A and Thread B) attempt to connect the same socket concurrently. Thread A proceeds to connect and change the socket state, while Thread B is blocked but then resumes and revives a socket that was closed and marked as zapped. This results in double socket release (sock_put()) and use-after-free, as well as leaking a connection object.

The fix involves acquiring the socket lock before checking the socket state and type to serialize concurrent connect attempts, properly returning errors for invalid socket types, re-checking the socket state after locking, preventing double attachment of sockets to connections, and cleaning up leaked connections on failure.


How can this vulnerability impact me? :

This vulnerability can lead to use-after-free conditions in the Linux kernel Bluetooth stack, which may cause system instability, crashes, or potentially allow an attacker to execute arbitrary code or escalate privileges by exploiting the corrupted memory state.

Additionally, the leak of connection objects can lead to resource exhaustion, potentially degrading system performance or causing denial of service.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by changes in the Linux kernel Bluetooth SCO code that prevent race conditions in sco_sock_connect(). Immediate mitigation steps include:

  • Update your Linux kernel to a version that includes the fix for this vulnerability.
  • Ensure that the kernel applies the following fixes: locking the socket before checking sk_state and sk_type, proper error returns on sk_type checks, re-checking state after locking, preventing double-attach of sockets, and preventing HCI connection leaks.

Without an updated kernel, there are no specific configuration or command-line mitigations described.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart