CVE-2026-80666: Bluetooth: sco: Fix a race condition in sco_sock_timeout()
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: sco: Fix a race condition in scosocktimeout()
scosocktimeout() runs asynchronously and locksock(sk). If the socket is closing while the timer is running, it holds the same lock (locksock(sk)) twice, leading to a deadlock.
CPU 0 CPU 1 ==================== ====================== scosockclose() scosocktimeout() locksock(sk) // <-- LOCK scosockclose() scochandel() scoconnput() scoconnfree() disabledelayedworksync() lock(sk) // <-- SAME LOCK
Fix this by moving disabledelayedworksync() outside of locksock(sk), ensuring that no locksock(sk) is held before scosocktimeout().
Lockdep splat:
WARNING: possible circular locking dependency detected 6.13.0-rc4 #7 Not tainted
syz-executor292/9514 is trying to acquire lock: ffff8881115d5070 ((workcompletion)(&(&conn->timeoutwork)->work)){+.+.}-{0:0}, at: rculockacquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline] ffff8881115d5070 ((workcompletion)(&(&conn->timeoutwork)->work)){+.+.}-{0:0}, at: rcureadlock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline] ffff8881115d5070 ((workcompletion)(&(&conn->timeoutwork)->work)){+.+.}-{0:0}, at: startflushwork sect/v6.13-rc4/kernel/workqueue.c:4137 [inline] ffff8881115d5070 ((workcompletion)(&(&conn->timeoutwork)->work)){+.+.}-{0:0}, at: flushwork+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195
but task is already holding lock: ffff88807db3a258 (sklock-AFBLUETOOTH-BTPROTOSCO){+.+.}-{0:0}, at: locksock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] ffff88807db3a258 (sklock-AFBLUETOOTH-BTPROTOSCO){+.+.}-{0:0}, at: scosockclose+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (sklock-AFBLUETOOTH-BTPROTOSCO){+.+.}-{0:0}: lockacquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 locksocknested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622 locksock sect/v6.13-rc4/./include/net/sock.h:1623 [inline] scosocktimeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158 processonework sect/v6.13-rc4/kernel/workqueue.c:3229 [inline] processscheduledworks+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310 workerthread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391 kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389 retfromfork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry64.S:244
-> #0 ((workcompletion)(&(&conn->timeoutwork)->work)){+.+.}-{0:0}: checkprevadd sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline] checkprevsadd sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline] validatechain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904 lockacquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226 lockacquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849 touchworklockdepmap sect/v6.13-rc4/kernel/workqueue.c:3909 [inline] startflushwork sect/v6.13-rc4/kernel/workqueue.c:4163 [inline] flushwork+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195 cancelworksync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline] disabledelayedworksync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514 scoconnfree sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline] krefput sect/v6.13-rc4/./include/linux/kref.h:65 [inline] scoconnput+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107 scochandel+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236 scosockclose+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526 scosockrelease+0x62/0x2d0 sect/v6.13-rc4/net/blueto ---truncated---
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.13.0-rc4
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Linux kernel systems using Bluetooth SCO sockets are exposed when a socket can be closed while its asynchronous timeout work is running. The affected path involves the SCO socket close and timeout handlers.
What condition is required to trigger the problem?
The socket must be closing at the same time that sco_sock_timeout() executes. The close path and timeout path can each acquire the same socket lock, creating a deadlock.
How can administrators identify a possible occurrence?
Kernel lockdep may report a possible circular locking dependency involving conn->timeout_work and the socket lock. A system may also exhibit a stuck Bluetooth SCO socket close operation due to the deadlock.
What is the available remediation?
Apply a kernel update containing the fix that moves disable_delayed_work_sync() outside lock_sock(sk). This ensures the timeout work is synchronized before the socket lock is held.