Look up another CVE · open CVE-2026-63944 in the interactive tracker
CVE-2026-63944
Bluetooth: hci_sync: fix UAF in hci_le_create_cis_sync
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem net/bluetooth. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-63944 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
hci_le_create_cis_sync() dereferences conn->conn_timeout after releasing both rcu_read_lock() and hci_dev_lock(hdev). The conn pointer was obtained from an RCU-protected iteration over hdev->conn_hash.list and is not valid once these locks are dropped. A concurrent disconnect can free the hci_conn between the unlock and the dereference, causing a use-after-free read. The cancellation mechanism in hci_conn_del() cannot prevent this because hci_le_create_cis_pending() queues hci_create_cis_sync with data=NULL: hci_cmd_sync_queue(hdev, hci_create_cis_sync, NULL, NULL); While hci_conn_del() dequeues with data=conn: hci_cmd_sync_dequeue(hdev, NULL, conn, NULL); Since NULL != conn, the lookup in _hci_cmd_sync_lookup_entry() never matches, and the pending work item is not cancelled. Fix this by saving conn->conn_timeout into a local variable while the locks are still held, so the stale conn pointer is never dereferenced after unlock. This is the same class of bug as the one fixed by commit 035c25007c9e ("Bluetooth: hci_sync: Fix UAF on le_read_features_complete") which addressed the identical pattern in a different function. This vulnerability was identified using 0sec.ai, an open-source automated security auditing platform (https://github.com/0sec-labs).
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/bluetooth/hci_sync.c
- What this is
- BLUETOOTH SUBSYSTEMMAINTAINERS section matched on net/bluetooth/ · linux-bluetooth@vger.kernel.org · Supported
- Kernel module
- bluetooth
Check it on the machine
grep -w CONFIG_BT /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w bluetoothPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_BT
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.33%, higher than 24.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- net/bluetooth
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.4 | 6.6.143 | a55618c0f4ce |
| 6.4 | 6.12.93 | a921957d3929 |
| 6.4 | 6.18.35 | d9019210c8c3 |
| 6.4 | 7.0.12 | 380e67b1794a |
| 6.4 | 7.1 | bfea6091e0ff |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:AAttack vector, adjacent network
- The bug is in the Bluetooth HCI ISO/CIS path (`hci_le_create_cis_sync`), reachable only via the Bluetooth radio interface. Per kernel CVSS guidance, Bluetooth vulnerabilities are scored as Adjacent, including on phones and LE Audio devices in public spaces.
- AC:LAttack complexity, low
- The UAF is a race between `hci_le_create_cis_sync` dropping locks and a concurrent `hci_conn_del`. An attacker who controls one side of the CIS setup (local ISO socket threads or a remote peer timing ACL/CIS teardown) can repeatedly trigger the race; success does not depend on uncontrollable conditions like kernel memory layout.
- PR:NPrivileges required, none
- No local Unix privileges are required for the highest-impact scenario: a remote Bluetooth peer in range can provoke CIS teardown/disconnect events while the victim host is performing normal LE Audio CIS establishment (e.g., phone connecting to earbuds). Local exploitation via ISO sockets also requires no special capabilities at the kernel level.
- UI:NUser interaction, none
- Both sides of the race run inside the kernel's own HCI event handling: hci_le_create_cis_pending() queues the vulnerable work from hci_le_cis_established_evt(), hci_cs_le_create_cis(), hci_unbound_cis_failed() and iso_connect_cfm(), all driven by controller events and remote peer traffic, while the freeing side is a peer-initiated disconnect reaching hci_conn_del(). On an LE Audio host the CIS establishment happens by itself when the earbuds connect and the attacker supplies the disconnect, so nothing is asked of the person holding the device; the existing pairing is a precondition of the deployment, not an in-attack user step.
- S:UScope, unchanged
- Impact is confined to kernel memory corruption within the Bluetooth subsystem on the host; this is standard kernel compromise, not a cross-boundary escape (KVM guest-to-host, IOMMU bypass, or sandbox breakout).
- C:HConfidentiality impact, high
- This is a slab use-after-free read of `conn->conn_timeout` on a freed `hci_conn` (kmalloc-8k object). UAF reads against attacker-influencable freed objects can disclose kernel heap contents and are scored as High per kernel CVSS guidance.
- I:HIntegrity impact, high
- Although the immediate bug is a post-unlock dereference of a freed `hci_conn`, UAF on large `hci_conn` kmalloc objects enables heap grooming and control of freed memory contents, which can be chained into arbitrary kernel writes or code execution; UAF class bugs are scored I:H.
- A:HAvailability impact, high
- Use-after-free access to a freed connection object can cause kernel oops/panic (as demonstrated by the same bug class in the related `le_read_features_complete` fix found by syzkaller). Even without full exploitation, triggering the UAF reliably causes High availability impact.