CVE-2024-41063

What it actually does

The vulnerability is a race condition in the Linux kernel Bluetooth HCI core where hci_unregister_dev fails to cancel pending works (rx_work, cmd_work, tx_work on workqueue and power_on, error_reset on req_workqueue) before hci_release_dev calls destroy_workqueue, allowing hci_error_reset invoked from req_workqueue to trigger hci_dev_put and deadlock at workqueue flush.

Why it matters to the business

Linux systems with Bluetooth enabled may experience kernel deadlocks or hangs during device error handling, resulting in system unavailability, forced reboots, and operational disruption on servers, desktops, and embedded devices.

How an attack unfolds

An attacker triggers Bluetooth HCI error conditions that invoke hci_error_reset from the request workqueue; this leads to device unregistration and an attempt to destroy the workqueue from within a queued work item, causing deadlock without the cancel_work_sync calls added in the fix.

How to fix it

Upgrade the Linux kernel to a fixed version containing commit 48542881997e17b49dc16b93fe910e0cfcf7a9f9 or stable releases such as 4.19.319 and later; apply the patch that adds cancel_work_sync calls for the affected work items in hci_unregister_dev.

How to confirm the fix worked

Confirm the presence of cancel_work_sync calls on rx_work, cmd_work, tx_work, power_on and error_reset inside hci_unregister_dev in the kernel source; reproduce Bluetooth device registration, error reset and unregistration sequences without observing deadlocks or hung tasks.

Typical attack path

1. Interact with Bluetooth stack to induce HCI error state
2. hci_error_reset executes from req_workqueue and calls hci_release_dev
3. Pending works remain on workqueues during destroy_workqueue
4. Kernel deadlocks attempting to flush the workqueue from itself

How to detect it

Inspect kernel logs and dmesg output for deadlock signatures, hung tasks, or warnings referencing destroy_workqueue, hci_release_dev, or hci_error_reset during Bluetooth activity; review system crash dumps for workqueue flush attempts from within req_workqueue.

What your security team should do

• Prioritize kernel upgrades on all systems exposing Bluetooth interfaces
• Temporarily disable Bluetooth via kernel configuration or hardware switch where feasible
• Monitor kernel logs for hung task warnings involving hci workqueues
• Validate the fix in staging environments before broad deployment