CVE-2026-89774: Bluetooth: SCO: hold sk properly in sco_conn_ready
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: SCO: hold sk properly in scoconnready
sk deref in scoconnready must be done either under conn->lock, or holding a refcount, to avoid concurrent close. conn->sk and parent sk is currently accessed without either, and without checking parent->skstate:
[Task 1] [Task 2] scosockrelease scoconnready sk = conn->sk locksock(sk) conn->sk = NULL locksock(sk) releasesock(sk) scosockkill(sk) UAF on sk deref
and similarly for access to scogetsocklisten() return value.
Fix possible UAF by holding sk refcount in scoconnready() and making scogetsocklisten() increase refcount. Also recheck after locksock that the socket is still valid. Adjust conn->sk locking so it's protected also by locksock() of the associated socket if any.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
The race involves concurrent SCO socket teardown and execution of sco_conn_ready(). An affected system must be using the Linux kernel Bluetooth SCO socket path, with a socket being closed while the connection-ready handler accesses the connection socket or its parent socket.
What is the likely impact if the race is triggered?
The issue can cause a use-after-free when sco_conn_ready() dereferences a socket after concurrent release has invalidated it. The provided data does not specify further impact such as privilege escalation or information disclosure.
How can I tell whether a kernel includes the fix?
The fix holds a socket reference in sco_conn_ready(), makes sco_get_sock_listen() return a referenced socket, revalidates the socket after lock_sock(), and protects conn->sk access with the associated socket lock. The listed stable-kernel references identify commits containing the remediation.