CVE-2025-68304 in Linux
Summary
by MITRE • 12/16/2025
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: lookup hci_conn on RX path on protocol side
The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b ("Bluetooth: convert conn hash to RCU") and not clear if it had purpose since then.
Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible.
Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup.
syzkaller has reported a crash that appears to be this issue:
[Task hdev->workqueue] [Task 2]
hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 05/24/2026
The vulnerability identified as CVE-2025-68304 resides within the Linux kernel's Bluetooth subsystem, specifically in the hci_core module responsible for handling Bluetooth hardware connections. This issue represents a use-after-free condition that occurs during the reception of Bluetooth packets, where the kernel fails to properly synchronize access to hci_conn data structures during the receive path. The flaw stems from an outdated locking mechanism that was originally designed to prevent concurrent modifications but has become obsolete since the implementation of RCU (Read-Copy-Update) in the connection hash table. The vulnerability manifests when multiple execution contexts attempt to access the same hci_conn structure simultaneously, with one context deleting the structure while another attempts to use it, leading to potential system instability or security exploitation.
The technical root cause involves the improper synchronization of hci_conn access during packet reception, where the existing locking pattern fails to prevent concurrent modifications to connection objects that can be deleted from different execution contexts. The hci_conn structures are accessed in the RX path without proper protection against simultaneous deletion operations that may occur from other kernel threads executing in the hdev->workqueue context. This creates a race condition where a connection object can be freed by one thread while another thread attempts to reference it during packet processing, resulting in a use-after-free scenario that can be exploited to cause system crashes or potentially achieve privilege escalation.
The operational impact of this vulnerability extends beyond simple system crashes to potentially enable more sophisticated attacks through the exploitation of the race condition. The use-after-free condition can be leveraged by malicious actors to corrupt kernel memory, potentially leading to arbitrary code execution with kernel privileges. The vulnerability is particularly concerning because it affects the core Bluetooth packet processing functionality, meaning any Bluetooth-enabled device running an affected kernel version could be compromised. Additionally, the vulnerability's presence in the receive path makes it difficult to detect and prevent through traditional network monitoring techniques, as the malicious behavior occurs at the kernel level.
Mitigation strategies should focus on implementing proper synchronization mechanisms around hci_conn access during packet reception, moving the lookup operations into a single critical section that encompasses both the connection lookup and usage phases. The solution involves restructuring the code to ensure that connection lookups and subsequent usage occur within a unified locking context that prevents concurrent access patterns that could lead to use-after-free conditions. This approach aligns with the principles of secure coding practices and addresses the fundamental flaw in the locking strategy that was inherited from earlier kernel versions. The fix should be implemented in accordance with CWE-416, which addresses use-after-free vulnerabilities, and should incorporate protections that align with ATT&CK framework techniques related to privilege escalation and kernel exploitation. System administrators should prioritize applying patches that implement the corrected locking mechanism to prevent exploitation of this vulnerability across all Bluetooth-enabled systems.