CVE-2024-53207

What it actually does

Race condition in Bluetooth MGMT handling allows hci_cmd_sync_dequeue to invoke a destroy callback while holding locks, resulting in deadlock on mutex acquisition during power-off or connectable state changes.

Why it matters to the business

Bluetooth-enabled Linux systems can experience prolonged task hangs, kernel worker stalls, and loss of Bluetooth functionality, disrupting wireless peripherals and device management on affected kernels.

How an attack unfolds

An attacker or local process triggers Bluetooth power state transitions or command completions that exercise the MGMT pending list while hci_cmd_sync_work runs, causing the deadlock path shown in the stack trace; no named threat actors are known to weaponize this race.

How to fix it

Update the Linux kernel to the commit 98f7e32f20d28ec452afb208f9cffc08448a2652 or later; rebuild and reboot with the patched Bluetooth and HCI modules.

How to confirm the fix worked

Confirm kernel version contains commit 98f7e32f20d28ec452afb208f9cffc08448a2652; reproduce power-off sequences under load and verify absence of hung-task warnings related to mgmt_pending_foreach or hci_cmd_sync_dequeue.

Typical attack path

1. Initiate Bluetooth device power-off or connectable state change via MGMT interface
2. Trigger concurrent hci_cmd_sync_work that dequeues commands
3. Force destroy callback execution under held mutex
4. Induce deadlock in mgmt_set_connectable_complete or __mgmt_power_off

How to detect it

Search kernel logs for hung_task_timeout entries citing kworker/u and bluetooth workqueues; inspect dmesg or journalctl for mgmt_set_connectable_complete and hci_dev_close_sync stack traces.

What your security team should do

• Prioritize kernel upgrade on all Bluetooth-enabled systems within 30 days
• Monitor for hung_task_timeout messages involving bluetooth and kworker threads
• Disable Bluetooth via rfkill when not required until patches are applied