---
id: CVE-2025-68304
title: |-
  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 concurre…
summary: |-
  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 concurre…
severity: high
cvss: 8.8
cvssVector: 'CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'
published: '2025-12-16'
updated: '2026-10-14'
sourceUpdated: '2026-10-14T16:10:00.250'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2025-68304'
references:
  - url: 'https://git.kernel.org/stable/c/79a2d4678ba90bdba577dc3af88cc900d6dcd5ee'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/ec74cdf77310c43b01b83ee898a9bd4b4b0b8e93'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
epss: 0.00233
epssPercentile: 0.13081
ingestedAt: '2026-10-14T16:40:32.053Z'
---

## Overview

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)

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.