In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: fix iso_conn related locking and validity issues
sk->skstate indicates whether isopi(sk)->conn is valid. Operations that check/update skstate and access conn should hold locksock, otherwise they can race.
The order of taking locks is hcidevlock > locksock > isoconnlock, which is how it is in connect/disconnectcfm -> isoconndel -> isochandel.
Fix locking in isoconnectcis/bis and sendmsg/recvmsg to take locksock around updating skstate and conn.
isoconndel must not occur during isoconnectcis/bis, as it frees the iso_conn. Hold hdev->lock longer to prevent that.
This should not reintroduce the issue fixed in commit 241f51931c35 ("Bluetooth: ISO: Avoid circular locking dependency"), since the we acquire locks in order. We retain the fix in isosockconnect to release locksock before isoconnect_* acquires hdev->lock.
Similarly for commit 6a5ad251b7cd ("Bluetooth: ISO: Fix possible circular locking dependency"). We retain the fix in isoconnready to not acquire isoconnlock before lock_sock.
isoconnadd shall return isoconn with valid hcon. Make it so also when reusing an old CIS connection waiting for disconnect timeout (see _isosockclose where conn->hcon is set to NULL).
isosockcreate:771: sock 00000000be9b69b7 isosockinit:693: sk 000000004dff667e isosockbind:827: sk 000000004dff667e 70:1a:b8:98:ff:a2 type 1 isosocksetsockopt:1289: sk 000000004dff667e isosocksetsockopt:1289: sk 000000004dff667e isosocksetsockopt:1289: sk 000000004dff667e isosockconnect:875: sk 000000004dff667e isoconnectcis:353: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da hcigetroute:1199: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da hciconnadd:1005: hci0 dst 28:3d:c2:4a:7e:da isoconnadd:140: hcon 000000007b65d182 conn 00000000daf8625e _isochanadd:214: conn 00000000daf8625e isoconnectcfm:1700: hcon 000000007b65d182 bdaddr 28:3d:c2:4a:7e:da status 12 isoconndel:187: hcon 000000007b65d182 conn 00000000daf8625e, err 16 isosockcleartimer:117: sock 000000004dff667e state 3 <Note: skstate is BTBOUND (3), so isoconnectcis is still running at this point> isochandel:153: sk 000000004dff667e, conn 00000000daf8625e, err 16 hciconndel:1151: hci0 hcon 000000007b65d182 handle 65535 hciconnunlink:1102: hci0: hcon 000000007b65d182 hcichanlistflush:2780: hcon 000000007b65d182 isosockgetsockopt:1376: sk 000000004dff667e isosockgetname:1070: sock 00000000be9b69b7, sk 000000004dff667e isosockgetname:1070: sock 00000000be9b69b7, sk 000000004dff667e isosockgetsockopt:1376: sk 000000004dff667e isosockgetname:1070: sock 00000000be9b69b7, sk 000000004dff667e isosockgetname:1070: sock 00000000be9b69b7, sk 000000004dff667e isosockshutdown:1434: sock 00000000be9b69b7, sk 000000004dff667e, how 1 _isosockclose:632: sk 000000004dff667e state 5 socket 00000000be9b69b7 <Note: skstate is BTCONNECT (5), even though isochandel sets BTCLOSED (6). Only isoconnectcis sets it to BTCONNECT, so it must be that isochandel occurred between isochanadd and end of isoconnectcis.> BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 8000000006467067 P4D 8000000006467067 PUD 3f5f067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014
isoconnectcis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da ... isoconnadd:140: hcon 0000000093bc551f conn 00000000768ae504 hcidevput:1487: hci0 orig refcnt 21 hcieventpacket:7607: hci0: e ---truncated---
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/54xxx/CVE-2023-54164.json",
"cna_assigner": "Linux"
}