CVE-2026-98735: Bluetooth: hci_core: Serialize ACL scheduling with channel deletion
Bluetooth: hcicore: Serialize ACL scheduling with channel deletion
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
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - 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
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
Bluetooth ACL or LE transmit scheduling must select a channel while a disconnect command timeout, running on a separate request workqueue, causes the associated connection and L2CAP channel to be deleted. The race occurs after transmit processing drops its RCU read lock and before it accesses the channel queue or transmit counters.
What components are involved in the affected race?
The race involves the Bluetooth HCI transmit workqueue, ACL or LE schedulers, and L2CAP channel teardown. A channel can be unlinked, have its queue purged, and be freed by hci_chan_del() while transmit processing still holds and uses the previously selected channel pointer.
How might an affected system reveal this issue?
The provided report shows KASAN detecting a slab use-after-free in hci_chan_sent() from hci_tx_work. Relevant call traces include hci_chan_del(), l2cap_conn_del(), hci_conn_failed(), and hci_abort_conn_sync() on the freeing path.