CVE-2025-40318 in Linux
Summary
by MITRE • 12/08/2025
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once
hci_cmd_sync_dequeue_once() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hci_cmd_sync_work() can also delete the same entry, leading to double list_del() and "UAF".
Fix this by holding cmd_sync_work_lock across both lookup and cancel, so that the entry cannot be removed concurrently.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 02/23/2026
The vulnerability identified as CVE-2025-40318 represents a critical race condition within the Linux kernel's Bluetooth subsystem, specifically affecting the hci_sync component responsible for handling synchronous Bluetooth commands. This flaw exists in the hci_cmd_sync_dequeue_once() function which performs a lookup operation followed by cancellation of entries under separate lock sections. The fundamental issue arises from the lack of atomicity in the operation sequence, creating a window where concurrent execution paths can interfere with each other during the critical section of the code. The vulnerability manifests when multiple threads or processes attempt to access the same Bluetooth command synchronization entry simultaneously, leading to a dangerous state where the same memory location may be freed and accessed multiple times.
The technical implementation of this race condition occurs within the Bluetooth HCI (Host Controller Interface) subsystem where the hci_cmd_sync_dequeue_once() function first acquires a lock to perform a lookup operation on a command synchronization entry, then releases this lock before acquiring another lock to cancel the entry. Meanwhile, the hci_cmd_sync_work() function operates concurrently and can delete the same entry that is being processed by the dequeue function, creating a scenario where the list_del() operation is called twice on the same memory location. This double deletion results in a use-after-free condition that allows for arbitrary code execution or system instability, as the freed memory can be reallocated and accessed by malicious actors. The vulnerability directly maps to CWE-367, which describes Time-of-Check to Time-of-Use (TOCTOU) race conditions, and represents a classic example of improper lock management in concurrent programming scenarios.
The operational impact of this vulnerability extends beyond simple system instability to potentially enable privilege escalation and remote code execution within the kernel space. An attacker who can control the timing of concurrent operations or has access to Bluetooth functionality can exploit this race condition to trigger the use-after-free scenario, potentially leading to complete system compromise. The vulnerability affects all Linux kernel versions that implement the Bluetooth HCI subsystem with the specific hci_sync functionality, making it particularly concerning for embedded systems, mobile devices, and servers that rely on Bluetooth connectivity. The attack surface includes any system where Bluetooth commands are processed synchronously and where multiple concurrent threads or processes might access the same command synchronization entries, which is common in mobile devices, laptops, and IoT systems with Bluetooth capabilities.
Mitigation strategies for CVE-2025-40318 focus on ensuring proper locking mechanisms are maintained throughout the entire critical section of the hci_cmd_sync_dequeue_once() function. The fix implemented by the Linux kernel developers requires holding the cmd_sync_work_lock across both the lookup and cancel operations, preventing concurrent access to the same entry during the entire process. This approach aligns with ATT&CK technique T1068 which describes the exploitation of privilege escalation vulnerabilities through kernel-level race conditions. System administrators should prioritize updating to kernel versions that include the patched implementation, as the vulnerability cannot be effectively mitigated through configuration changes or workarounds. Additionally, monitoring for unusual Bluetooth activity or kernel memory access patterns can help detect potential exploitation attempts, though the race condition itself is difficult to detect through standard security measures due to its timing-dependent nature. The fix represents a fundamental improvement in concurrent programming practices and demonstrates the importance of maintaining atomicity in multi-threaded kernel operations to prevent similar vulnerabilities from occurring in other subsystems.