CVE-2026-80764 Overview
CVE-2026-80764 is a use-after-free vulnerability in the Linux kernel Bluetooth subsystem. The flaw resides in the hci_cc_reset() function within the HCI (Host Controller Interface) event handler. During a controller reset, the function clears the LE (Low Energy) accept and resolving lists without acquiring hdev->lock. Other command-complete handlers and debugfs readers rely on this lock to synchronize access to those lists. The missing lock allows a debugfs reader to dereference a freed list entry and follow a stale next pointer. KASAN identified the issue as a slab-use-after-free read in white_list_show().
Critical Impact
Concurrent Bluetooth controller reset and debugfs reads can trigger kernel memory corruption, potentially leading to denial of service or local privilege escalation on affected Linux systems.
Affected Products
- Linux kernel Bluetooth subsystem (net/bluetooth/hci_event.c)
- Multiple stable kernel branches receiving backported fixes
- Any distribution shipping affected kernel versions with Bluetooth enabled
Discovery Timeline
- 2026-09-04 - CVE-2026-80764 published to NVD
- 2026-09-04 - Last updated in NVD database
Technical Details for CVE-2026-80764
Vulnerability Analysis
The vulnerability is a use-after-free condition in the Linux kernel Bluetooth HCI event processing path. When a Bluetooth controller reset completes, hci_cc_reset() invokes hci_bdaddr_list_clear() on both the LE accept list and the LE resolving list. These clears free every entry in the linked list without holding hdev->lock.
All other mutators of these lists (for example, hci_cc_le_add_to_accept_list()) and the debugfs readers such as white_list_show() acquire hdev->lock before walking or modifying the lists. Because the reset path breaks this convention, a debugfs reader that has already taken the lock and fetched an entry pointer can race with the reset work.
The reader reads fields from an entry after list_del() and kfree() have run on the reset side, producing a slab use-after-free. Following the stale next pointer can extend the corruption into arbitrary freed slab memory.
Root Cause
The root cause is a locking convention violation. hci_cc_reset() calls hci_bdaddr_list_clear() on the le_accept_list and le_resolv_list without holding hdev->lock, while every other path that mutates or traverses these lists acquires the lock. The asymmetric locking breaks the memory-safety guarantees the readers depend on.
Attack Vector
Exploitation requires a local attacker capable of reading the Bluetooth debugfs entries (for example, /sys/kernel/debug/bluetooth/hci0/white_list) concurrently with triggering an HCI reset. Under normal permissions, debugfs is restricted, but any process able to reach both the reset trigger and the debugfs read can race the two code paths. The result is a slab use-after-free read, as demonstrated by the KASAN report captured in the upstream commit message showing the read in white_list_show() against memory freed by hci_bdaddr_list_clear() via hci_cc_reset().
No verified public proof-of-concept code is available. Refer to the upstream commits linked below for the authoritative technical detail.
Detection Methods for CVE-2026-80764
Indicators of Compromise
- KASAN reports containing slab-use-after-free in white_list_show or references to hci_bdaddr_list_clear in the free stack.
- Unexpected kernel oops or panic traces originating in hci_rx_work, hci_event_packet, or hci_cmd_complete_evt.
- Bluetooth stack instability correlated with controller resets on systems with debugfs readers active.
Detection Strategies
- Enable KASAN on test kernels to surface the exact use-after-free pattern documented in the upstream commit.
- Compare running kernel versions against the fixed commits (0628cc9b, 25b05e3c, 33af47e8, 39a3afb9, 8e68c380, b55e83a4, d57702d4) to identify unpatched hosts.
- Monitor kernel ring buffers (dmesg, journalctl -k) for Bluetooth subsystem faults following reset events.
Monitoring Recommendations
- Ship kernel logs to a centralized platform and alert on Bluetooth stack crash signatures.
- Track processes accessing /sys/kernel/debug/bluetooth/* on production systems where debugfs should not be readable.
- Inventory kernel package versions across the fleet and flag hosts running builds older than the backport releases listed by each distribution.
How to Mitigate CVE-2026-80764
Immediate Actions Required
- Apply the upstream kernel patches or vendor-supplied backports to all affected systems.
- Restrict access to Bluetooth debugfs entries by ensuring debugfs is mounted with restrictive permissions or not mounted on production hosts.
- Disable the Bluetooth subsystem on servers and appliances that do not require it, using rmmod bluetooth or blacklisting the module.
Patch Information
The fix takes hdev->lock around both list clears in hci_cc_reset(), aligning the reset path with the existing mutation and traversal locking convention. The patch is available across multiple stable branches. See the upstream commits: Kernel Patch 0628cc9b, Kernel Patch 25b05e3c, Kernel Patch 33af47e8, Kernel Patch 39a3afb9, Kernel Patch 8e68c380, Kernel Patch b55e83a4, and Kernel Patch d57702d4.
Workarounds
- Unload the Bluetooth kernel modules on systems that do not need Bluetooth functionality.
- Prevent unprivileged mounting or reading of debugfs to close the race window against white_list_show() and related readers.
- Limit exposure to untrusted local users on hosts that must run vulnerable kernels until patches are deployed.
# Prevent Bluetooth module loading until the kernel is patched
echo 'blacklist bluetooth' | sudo tee /etc/modprobe.d/disable-bluetooth.conf
echo 'blacklist btusb' | sudo tee -a /etc/modprobe.d/disable-bluetooth.conf
sudo rmmod btusb bluetooth 2>/dev/null || true
# Ensure debugfs is not world-readable
sudo mount -o remount,mode=700 /sys/kernel/debug
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.