CVE-2026-98246: Bluetooth: hci_sync: Serialize local codec list cleanup
Bluetooth: hcisync: Serialize local codec list cleanup
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.6.158.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
Modify hci_dev_close_sync() to take hdev->lock around the existing hci_codec_list_clear() operation, so cleanup waits for active readers and prevents new traversals until the codec list is empty.
Event History
Frequently Asked Questions
What conditions are required to trigger the issue?
A Bluetooth device close operation must overlap with a BT_CODEC query through sco_sock_getsockopt(). The query can fetch a codec-list entry while the close path frees that entry.
Which code path is exposed to the use-after-free?
The affected reader is sco_sock_getsockopt(), which traverses the local codec list under hdev->lock. The unsafe concurrent writer is hci_dev_close_sync(), which previously cleared that list after releasing the lock.
How can an affected system be recognized?
KASAN may report a slab-use-after-free in sco_sock_getsockopt, including a read of a codec entry after hci_codec_list_clear freed it. The reported call trace includes sco_sock_getsockopt, do_sock_getsockopt, and __sys_getsockopt.
What does the fix change?
The fix takes hdev->lock around local codec list cleanup at the existing point in the device close path. This makes cleanup wait for active readers and prevents new traversals until the list is empty.