CVE-2026-80762 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: Fix accept list UAF during suspend
hci_update_event_filter_sync() walks hdev->accept_list while sending a synchronous HCI command for each remote-wakeup device. The suspend path holds hdev->req_lock, but accept-list updates are serialized by hdev->lock. Consequently, remove_device() can free the current list entry during the controller wait.
The following interleaving causes the use-after-free:
hci_update_event_filter_sync() remove_device() fetch accept-list entry hci_set_event_filter_sync() wait for controller response hci_dev_lock() list_del() kfree() hci_dev_unlock() read the freed list.next
KASAN reported:
BUG: KASAN: slab-use-after-free in hci_suspend_sync+0x835/0x910 Read of size 8 at addr ffff88810bec8440 by task kworker/0:1/10 Workqueue: events vhci_suspend_work Call Trace: hci_suspend_sync+0x835/0x910 hci_suspend_dev+0x182/0x450 process_one_work+0x661/0x1090 worker_thread+0x45b/0xd10
Allocated by task 86: hci_bdaddr_list_add_with_flags+0x1a8/0x400 add_device+0x381/0x820 hci_sock_sendmsg+0x1033/0x1ea0
Freed by task 91: kfree+0x131/0x3c0 remove_device+0x429/0xb70 hci_sock_sendmsg+0x1033/0x1ea0
Snapshot the remote-wakeup addresses under hdev->lock. Release the lock before sending HCI commands. Clear the controller event filter before building the snapshot, and skip allocation and the second list traversal when there are no matching entries. This preserves the original filter and scan-state updates without retaining an accept-list node across a controller wait.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/06/2026
The Linux kernel Bluetooth subsystem contains a critical use-after-free vulnerability within the hci_sync module that manifests during device suspend operations. The core of this issue lies in a race condition between the suspension process and dynamic list modifications involving remote-wakeup devices. Specifically, the function hci_update_event_filter_sync iterates over the hdev->accept_list to send synchronous Host Controller Interface commands for each configured remote-wakeup device. While the suspend path correctly acquires the hdev->req_lock to serialize certain operations, it fails to acquire the hdev->lock which is responsible for serializing updates to the accept list itself. This discrepancy in locking granularity creates a window of vulnerability where concurrent modifications can occur while the suspension logic is actively processing list entries.
The operational impact arises from an interleaving execution scenario that leads directly to memory corruption. During the suspend sequence, hci_update_event_filter_sync fetches an entry from the accept list and subsequently calls hci_set_event_filter_sync to configure the controller. This function initiates a synchronous HCI command and then waits for a response from the hardware controller. Because this wait period occurs while holding only the req_lock but not the lock protecting the accept list, another thread executing remove_device can intervene. The removal process acquires hdev->lock, deletes the node currently being processed by the suspend logic using list_del, and frees its memory via kfree before releasing the lock. When the original suspension task resumes after waiting for the controller response, it attempts to read from the freed memory address, specifically accessing the next pointer in the linked list structure. This results in a use-after-free condition that can lead to kernel crashes, data corruption, or potentially arbitrary code execution if an attacker can influence the contents of the freed slab cache.
This vulnerability is classified under CWE-416, Use After Free, as it involves accessing memory after it has been returned to the system for reuse without ensuring its validity remains intact relative to the current context. From a threat modeling perspective aligned with MITRE ATT&CK techniques, this flaw represents an opportunity for local privilege escalation or denial of service through kernel panic if triggered by a malicious user-space application capable of rapidly adding and removing Bluetooth devices during suspend cycles. The vulnerability highlights the importance of consistent locking strategies across all code paths that interact with shared data structures, particularly when those interactions involve blocking operations such as waiting for hardware responses.
The resolution involves restructuring the synchronization logic to ensure atomicity between list traversal and modification. The fix requires snapshotting the remote-wakeup addresses while holding hdev->lock, thereby capturing a consistent view of the list before any modifications can occur. Once the snapshot is created, the lock is released prior to sending HCI commands, eliminating the window where concurrent removal could corrupt the iteration state. Additionally, the controller event filter is cleared before building this snapshot to ensure accurate configuration updates. The logic also includes optimizations to skip allocation and secondary list traversals when no matching entries exist, improving efficiency while maintaining safety. This approach ensures that no accept-list node reference persists across a controller wait period where it could be invalidated by concurrent removal operations.
To mitigate similar issues in the future, developers must rigorously audit all code paths involving shared data structures to ensure that locking granularity matches the scope of critical sections. In this specific case, extending the hold time of hdev->lock or restructuring the suspend logic to decouple list iteration from hardware waits would prevent such race conditions. System administrators should apply kernel updates containing this fix immediately to close the exposure window. Security teams monitoring for anomalies in Bluetooth subsystem stability during power state transitions may find value in logging and analyzing kworker thread behavior, as repeated triggers of similar races could indicate exploitation attempts or system instability requiring immediate attention.