CVE-2026-80764: Bluetooth: hci_event: fix LE list UAF on reset
Bluetooth: hcievent: fix LE list UAF on reset
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.157.1-1 - 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 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.185 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.154 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.106 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.47 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.1.11 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.1 - Configuration
Take hdev->lock around both list clears in hci_cc_reset() so reset completion cannot interleave with debugfs readers walking the lists.
Linux kernel Bluetooth hci_event hci_cc_reset() hdev->lock = held around both LE accept-list and resolving-list clears
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
A Bluetooth reset command completion must clear the LE accept or resolving list while a debugfs reader is walking the same list. The race occurs because reset handling clears entries without hdev->lock, while the debugfs reader relies on that lock during traversal.
Which systems are exposed to this race?
Systems using the Linux kernel Bluetooth stack are exposed when the relevant LE lists can be read through debugfs concurrently with Bluetooth reset completion processing. The issue affects both the LE accept list and LE resolving list.
How might this appear during testing or incident investigation?
KASAN can report a slab use-after-free in white_list_show, with a read from a freed list entry during seq_read processing. The reported free path includes hci_bdaddr_list_clear called from hci_cc_reset.