CVE-2026-80764: Bluetooth: hci_event: fix LE list UAF on reset
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hcievent: fix LE list UAF on reset
hciccreset() clears the LE accept and resolving lists without taking hdev->lock. Other command-complete handlers serialize updates to these lists with that lock, and the debugfs readers hold it while walking them.
This permits the reset completion and a debugfs read to interleave as follows:
hcirxwork debugfs reader ----------- -------------- lock hdev->lock fetch current entry listdel(entry) kfree(entry) read entry fields
The reader then dereferences a freed list entry and may follow its stale next pointer.
KASAN reported:
BUG: KASAN: slab-use-after-free in whitelistshow+0x15f/0x180 Read of size 1 at addr ffff8881015dab16 by task poc/95
Call Trace: whitelistshow+0x15f/0x180 seqreaditer+0x3ff/0x1190 seqread+0x267/0x3d0 vfsread+0x177/0xa20 ksysread+0xf7/0x1c0
Allocated by task 91: hcibdaddrlistadd+0x1a6/0x3a0 hciccleaddtoacceptlist+0xab/0x140 hcicmdcompleteevt+0x26c/0x9a0 hcieventpacket+0x454/0xb20 hcirxwork+0x293/0x730
Freed by task 90: kfree+0x131/0x3c0 hcibdaddrlistclear+0xd8/0x160 hciccreset+0x28a/0x370 hcicmdcompleteevt+0x26c/0x9a0 hcieventpacket+0x454/0xb20 hcirxwork+0x293/0x730
Take hdev->lock around both list clears. This matches the existing mutation and traversal locking convention.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the kernel Bluetooth code so that hci_cc_reset() takes hdev->lock while clearing LE accept and resolving lists, and ensure the debugfs reader (white_list_show/seq_read path) holds hdev->lock while walking the list entries to prevent slab use-after-free interleaving during reset completion and debugfs read.
Linux kernel Bluetooth (hci) debugfs LE accept list / white_list_show hdev->lock synchronization around LE accept and resolving list clear and debugfs traversal = Take hdev->lock around both list clears and also hold it while walking lists in debugfs reader
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.