CVE-2026-97977 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: Fix UAF of btusb_data by rx_work
btusb_close() and btusb_flush() cancel data->rx_work with the asynchronous cancel_delayed_work(), so if btusb_rx_work() is already running on another CPU it keeps running after the cancel returns.
btusb_disconnect() calls hci_unregister_dev(), which invokes btusb_close(), and then frees the btusb_data. A still running btusb_rx_work() then dereferences the freed data:
while ((skb = skb_dequeue(&data->acl_q))) data->recv_acl(data->hdev, skb);
Use cancel_delayed_work_sync() instead. In btusb_close() the cancel also has to happen after btusb_stop_traffic(), otherwise an URB completion racing with the cancel can requeue the work right after it has been waited for.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel Bluetooth USB driver contains a critical use-after-free vulnerability arising from improper synchronization of asynchronous work items during device disconnection and closure operations. This flaw, identified in the btusb subsystem, occurs when the system attempts to stop traffic and clean up resources associated with a Bluetooth USB adapter. The core issue lies in the interaction between the cancellation mechanism for delayed work queues and the lifecycle management of the underlying data structures. Specifically, functions such as btusb_close and btusb_flush utilize cancel_delayed_work to attempt stopping the rx_work tasklet which handles incoming data processing. However, this function only ensures that future invocations are prevented; it does not guarantee that a currently executing instance on another CPU core will terminate immediately upon return.
When a Bluetooth device is disconnected, the kernel invokes hci_unregister_dev, which subsequently calls btusb_close to halt operations and then proceeds to free the associated btusb_data structure via kfree or similar memory management routines. If an rx_work item was already scheduled and executing on a different processor core at that moment, it continues to run even after the cancellation function returns. Consequently, this lingering execution context attempts to access members of the now-freed data structure. The code path involves dequeuing sockets from the acl_q queue and invoking recv_acl callbacks, all of which rely on valid pointers within btusb_data. Dereferencing these freed memory addresses leads to undefined behavior, typically manifesting as a kernel panic or system crash due to invalid memory access.
This vulnerability represents a classic race condition where timing dependencies between resource deallocation and asynchronous task execution are not properly enforced. From a classification perspective, this aligns with CWE-416, Use After Free, as the program continues to use a pointer after it has been freed. Furthermore, the exploitation vector relates to ATT&CK technique T1059, Command and Scripting Interpreter, if an attacker can trigger specific conditions that lead to code execution via memory corruption, though primarily this is categorized under privilege escalation or denial of service depending on whether arbitrary code execution is achieved through heap spraying techniques following the initial crash. The operational impact includes severe system instability, potential loss of data integrity during active transfers, and possible remote exploitation if an attacker can induce disconnection events while maintaining high-volume traffic to increase the probability of hitting the race window.
The resolution involves replacing cancel_delayed_work with cancel_delayed_work_sync in btusb_close. This synchronous variant ensures that any currently running instance of the work item is fully completed before the function returns, thereby guaranteeing that no dangling references exist when memory is subsequently freed. Additionally, the patch enforces a strict ordering where cancellation occurs only after btusb_stop_traffic has been called. This prevents a race condition where an USB completion interrupt could requeue the work item immediately after it was waited for but before traffic stopping logic had fully quiesced all pending operations. Implementing this fix requires careful attention to lock dependencies and ensures that all asynchronous tasks are properly synchronized with resource lifecycle events, thereby eliminating the window of opportunity for use-after-free exploitation in the Bluetooth USB stack.