CVE-2025-68304
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-12-16

Last updated on: 2025-12-18

Assigner: kernel.org

Description
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)
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-16
Last Modified
2025-12-18
Generated
2026-05-07
AI Q&A
2025-12-16
EPSS Evaluated
2026-05-05
NVD
CVE-2025-68304
EUVD
EUVD-2025-203776
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel's Bluetooth subsystem involves improper locking and lookup of hci_conn objects on the RX (receive) path. The existing locking mechanism does not prevent concurrent modification or deletion of hci_conn pointers, which can lead to use-after-free (UAF) conditions. The issue arises because some code paths delete hci_conn objects outside the expected workqueue context, causing race conditions. The fix involves moving the lookup and usage of hci_conn into a single critical section to ensure safe concurrent access and prevent UAF crashes.


How can this vulnerability impact me? :

This vulnerability can cause crashes in the Bluetooth subsystem of the Linux kernel due to use-after-free errors. Such crashes may lead to denial of service by destabilizing Bluetooth connectivity or the kernel itself. In some cases, use-after-free vulnerabilities can be exploited to execute arbitrary code or escalate privileges, but the description primarily indicates crash risks.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability has been resolved in the Linux kernel by improving locking mechanisms around hci_conn usage in the Bluetooth hci_core RX path. Immediate mitigation steps include updating your Linux kernel to a version that includes the fix for this issue, which involves moving the lookup of hci_conn and associated socket-specific connections to protocol receive handlers within a single critical section to prevent use-after-free conditions.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart