CVE-2026-98736: Bluetooth: hci_conn: Lock parent access during enhanced SCO setup
Bluetooth: hciconn: Lock parent access during enhanced SCO setup
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Upgrade
Upgrade
azurelinux/kernelto a version that resolves this vulnerability.Fixed in 6.6.161.1-1 - Compensating control
In hci_enhanced_setup_sync(), hold hci_dev_lock() across the codec switch, including every call to find_next_esco_param(), release it on all parameter-selection errors, and keep configure_datapath_sync() outside the critical section because it waits for HCI events.
Event History
Frequently Asked Questions
What conditions are needed to trigger this issue?
The issue requires enhanced SCO setup to be queued while its ACL parent connection is concurrently disconnected and released. The vulnerable path runs on the request workqueue, while receive processing can unlink and free the parent connection.
Which connection types are involved?
A queued SCO child connection and its ACL parent connection are involved. The unsafe accesses include the parent's feature data during CVSD capability checking and eSCO parameter selection.
How can I determine whether a kernel includes a fix?
Check whether the kernel contains one of the fixes referenced by commits 1239ef0fa809b5952fca679db3faa3e1c00e1dac, cabd58d9bb66d49d481f762ce986173db397435d, or 93a737e4e042f59673cd580d35214f278d7b757d. The earlier commit 42de40abe25d addresses the queued SCO child lifetime but does not protect these parent accesses.