CVE-2026-97977: Bluetooth: btusb: Fix UAF of btusb_data by rx_work
Bluetooth: btusb: Fix UAF of btusbdata by rxwork
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.158.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - 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
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems using the Linux kernel Bluetooth USB driver (btusb) are exposed when the driver is handling Bluetooth traffic and the device is closed, flushed, or disconnected while its receive work may be running.
What conditions are required to trigger the use-after-free?
The receive worker, btusb_rx_work(), must already be running on another CPU when btusb_close() or btusb_flush() attempts to cancel it, followed by device disconnect and freeing of btusb_data. A racing URB completion can also requeue the work if traffic is not stopped before synchronized cancellation.
Is stopping traffic part of the required fix?
Yes. Synchronized cancellation with cancel_delayed_work_sync() must occur after btusb_stop_traffic() in btusb_close(); otherwise an URB completion can requeue the receive work after cancellation has been waited for.
How can I determine whether the issue is fixed?
Check whether the btusb driver uses cancel_delayed_work_sync() for data->rx_work in btusb_close() and btusb_flush(), and verify that btusb_close() calls btusb_stop_traffic() before synchronously cancelling the receive work.