CVE-2025-68304
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 ...
Affects 1 product across 9 vendors.
A concurrency issue in the Bluetooth hci_core module of the Linux kernel could allow an attacker to potentially exploit the vulnerability to cause a denial of service or other unspecified impacts.
BSID: BS-2025-GLOBAL-029996-I • Model: /workspace/models/qwen2.5-coder-32b-instruct-bf16 • Confidence: MEDIUM
Is this CVE in your environment?
BreachSpider monitors your ICS/OT environment for vulnerabilities like this one. No agents or network access required. Free to start.
Check My Environment →What is CVE-2025-68304?
What is the CVSS score for CVE-2025-68304?
Is CVE-2025-68304 actively exploited?
How do I remediate CVE-2025-68304?
What systems are affected by CVE-2025-68304?
| CVE ID | CVE-2025-68304 |
|---|---|
| BSID | BS-2025-GLOBAL-029996-I BreachSpider Global ID |
| CVSS Vector | CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| Published | 2025-12-16 |
| Last Modified | 2026-10-15 |
| ICS Relevance | 0% |
| Source | NVD |
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)
Source: NIST NVD / MITRE CVE Database
The vulnerability arises from an improper handling of the hci_conn object in the packet RX path, where the hdev lock/lookup/unlock/use pattern does not ensure that the hci_conn object is not concurrently modified or deleted. This issue is a result of outdated locking mechanisms that were not updated when the connection hash was converted to use RCU.
Exploitation Likelihood: MEDIUM
| Vendor | Product | Affected Versions |
|---|---|---|
| Associated | — | — |
| Bluetooth | — | — |
| Clear | — | — |
| Kernel | — | — |
| Linux | Linux | 6.6 ≥ 6.1.149, < 6.2 ≥ 6.4.16, < 6.5 ≥ 6.5.3, < 6.6 |
| Lookup | — | — |
| Modified | — | — |
| Protocol | — | — |
| Socket | — | — |
No official vendor advisory link on record. See the CVE record →
| CISA known-exploited | Not in KEV catalog |
|---|---|
| Public Exploit | Not confirmed |
| PoC Code | Not confirmed |
AI Enrichment Record — provenance & audit hash
| Model | /workspace/models/qwen2.5-coder-32b-instruct-bf16 |
|---|---|
| Confidence | MEDIUM |
| Enriched At | 2026-05-24 |
| SHA-512 Audit Hash | 72e93bea277016aec41b005233dc4a6c77688571c7c6d65b7f0b83971b69f49715783a4083ad9e096f8df095f87b9c0f8f580de6d2936afda980e54c281d079b |
ICS/OT Vulnerability Intelligence for Your Environment
BreachSpider tracks 384,000+ CVEs and matches them to your ICS/OT assets by exact version, with AI analysis, NERC CIP mapping, and vendor PSIRT contacts.
Create a free account →