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

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: SCO: fix race conditions in scosockconnect()

scosockconnect() checks skstate and sktype without holding the socket lock. Two concurrent connect() syscalls on the same socket can both pass the check and enter scoconnect(), 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):

scosockconnect(sk) scosockconnect(sk) skstate==BTOPEN skstate==BTOPEN (pass, no lock) (pass, no lock) scoconnect(sk): scoconnect(sk): hcidevlock hcidevlock hciconnectsco <- blocked -> hcon1 scoconnadd->conn1 locksock(sk) scochanadd: conn1->sk = sk sk->conn = conn1 skstate=BTCONNECT releasesock hcidevunlock hcidevlock scoconndel: locksock(sk) scochandel: sk->conn=NULL conn1->sk=NULL skstate= BTCLOSED SOCKZAPPED releasesock hcidevunlock (unblocked) hciconnectsco -> hcon2 scoconnadd -> conn2 locksock(sk) scochanadd: sk->conn=conn2 skstate= BTCONNECT // zombie sk! releasesock hcidevunlock

Thread B revives a BTCLOSED + SOCKZAPPED socket back to BTCONNECT. Subsequent cleanup triggers double sockput() and use-after-free. Meanwhile conn1 is leaked as it was orphaned when scoconndel() cleared the association.

Fix this by: - Moving locksock() before the skstate/sktype checks in scosockconnect() to serialize concurrent connect attempts - Fixing the sktype != SOCKSEQPACKET check to actually return the error instead of just assigning it - Adding a state re-check in scoconnect() after locksock() to catch state changes during the window between the locks - Adding scopi(sk)->conn check in scochanadd() to prevent double-attach of a socket to multiple connections - Adding hciconndrop() on scochanadd failure to prevent HCI connection leaks