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)

No CVSS v4.0

Attack Vector Local

Attack Complexity High

Privileges Required Low

Scope Unchanged

Confidentiality Impact High

Integrity Impact High

Availability Impact High

User Interaction None

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

The EPSS score is 0.00027.

Key SSVC decision points have not yet been added.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions
Linux Linux unaffected
Version Status Constraints
5af1f84ed13a416297ab9ced7537f4d5ae7f329a affected < ec74cdf77310c43b01b83ee898a9bd4b4b0b8e93
5af1f84ed13a416297ab9ced7537f4d5ae7f329a affected < 79a2d4678ba90bdba577dc3af88cc900d6dcd5ee
cd55c13bbb3d093ae601aa97e588ed4c1390ebb1 affected —
4d3ca4a9aaf0aa798a6be372dc0fc3a29e37dd57 affected —
80265dd1d944c3f33e52375b5dbe654980bd2688 affected —
Linux Linux affected
Version Status Constraints
6.6 affected —
0 unaffected < 6.6
6.17.11 unaffected ≤ 6.17.*
6.18 unaffected ≤ *

No data.

No data.

No data.

Project Subscriptions

Vendors Products
Linux Subscribe
Linux Kernel Subscribe
Advisories

No advisories yet.

Fixes

Solution

No solution given by the vendor.

Workaround

No workaround given by the vendor.

References
Link Providers
https://git.kernel.org/stable/c/79a2d4678ba90bdba577dc3af88cc900d6dcd5ee cve-icon cve-icon
https://git.kernel.org/stable/c/ec74cdf77310c43b01b83ee898a9bd4b4b0b8e93 cve-icon cve-icon
https://lore.kernel.org/linux-cve-announce/2025121644-CVE-2025-68304-9ae7@gregkh/T cve-icon
https://nvd.nist.gov/vuln/detail/CVE-2025-68304 cve-icon
https://www.cve.org/CVERecord?id=CVE-2025-68304 cve-icon
History

Wed, 17 Dec 2025 00:15:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

 cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Important

Tue, 16 Dec 2025 15:30:00 +0000

Type Values Removed Values Added
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)
Title Bluetooth: hci_core: lookup hci_conn on RX path on protocol side
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Projects

Sign in to view the affected projects.

cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2025-12-16T15:06:21.887Z

Reserved: 2025-12-16T14:48:05.294Z

Link: CVE-2025-68304

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2025-12-16T16:16:09.930

Modified: 2025-12-18T15:08:06.237

Link: CVE-2025-68304

cve-icon Redhat

Severity : Important

Publid Date: 2025-12-16T00:00:00Z

Links: CVE-2025-68304 - Bugzilla

cve-icon OpenCVE Enrichment

No data.

Weaknesses

No weakness.