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)
References
Configurations
No configuration.
History
30 Jul 2026, 06:24
| Type | Values Removed | Values Added |
|---|---|---|
| CVSS |
v2 : v3 : |
v2 : unknown
v3 : 8.8 |
16 Dec 2025, 16:16
| Type | Values Removed | Values Added |
|---|---|---|
| New CVE |
Information
Published : 2025-12-16 16:16
Updated : 2026-07-30 06:24
NVD link : CVE-2025-68304
Mitre link : CVE-2025-68304
CVE.ORG link : CVE-2025-68304
JSON object : View
Products Affected
No product.
CWE
No CWE.