CVE-2024-49951 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix possible crash on mgmt_index_removed
If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace:
0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth]
0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth]
0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth]
So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 03/18/2026
The vulnerability CVE-2024-49951 represents a critical race condition and memory management flaw within the Linux kernel's Bluetooth subsystem, specifically affecting the Bluetooth Management (MGMT) interface. This issue manifests when the mgmt_index_removed function is invoked while command queues remain active in the cmd_sync mechanism, creating a scenario where the kernel can crash due to improper handling of queued operations. The flaw resides in the Bluetooth subsystem's ability to manage concurrent operations during device removal processes, where the system attempts to clean up resources while simultaneously processing pending commands.
The technical implementation of this vulnerability stems from improper synchronization between the Bluetooth management interface and command processing mechanisms. When mgmt_index_removed executes, it attempts to remove pending commands from the cmd_sync queue that were passed as user_data parameters. However, the existing code structure does not adequately protect against concurrent access patterns, leading to potential double-free conditions, use-after-free errors, or invalid memory dereferences. The stack trace indicates that the crash occurs during __list_del_entry_valid_or_report execution, suggesting that the system attempts to remove entries from a linked list structure that may already have been modified or freed by concurrent operations. This represents a classic race condition scenario where multiple execution paths attempt to modify shared data structures without proper locking mechanisms.
The operational impact of CVE-2024-49951 extends beyond simple system crashes, potentially enabling denial-of-service conditions that can affect Bluetooth-enabled devices across various Linux distributions. Attackers could exploit this vulnerability by triggering specific sequences of Bluetooth management commands followed by device removal operations, causing system instability and service disruption. The vulnerability affects systems where Bluetooth management operations are actively processed, particularly those running kernel versions containing the affected code paths. This issue is particularly concerning in embedded systems, mobile devices, and servers that rely on Bluetooth connectivity for various services, as it could be leveraged to create persistent availability issues or potentially escalate privileges through system instability.
Mitigation strategies for CVE-2024-49951 should focus on implementing proper synchronization mechanisms within the Bluetooth management subsystem. The primary fix involves adding appropriate locking primitives around the cmd_sync queue operations to prevent concurrent access during mgmt_index_removed execution. System administrators should prioritize applying kernel updates that contain the patched Bluetooth management code, which typically includes mutex or spinlock implementations to protect shared data structures. Organizations should also consider implementing monitoring for unusual Bluetooth command sequences that might indicate exploitation attempts. This vulnerability aligns with CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and may map to ATT&CK technique T1499.001 (Endpoint Denial of Service) in threat modeling contexts, emphasizing the need for robust concurrency control in kernel-level Bluetooth implementations. The fix requires careful consideration of performance implications while ensuring that the synchronization mechanisms do not introduce new bottlenecks in the Bluetooth command processing pipeline.