Look up another CVE · open CVE-2026-68394 in the interactive tracker
CVE-2026-68394
Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update
Published 2026-08-10 (2 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-68394 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.101-1 | Update the kernel and reboot. Fixed in 6.12.101-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4745-1 · 2026-08-18 · text | 6.12.101-1~deb12u1 | Update the kernel and reboot. DLA-4745-1 shipped the fix on 2026-08-18, in 6.12.101-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: <TASK> dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth]
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/mgmt.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
- bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64
- 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-08-10 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.12%, higher than 2.0% 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.11 | 6.12.101 | 65ce6fe1b921 |
| 6.11 | 6.18.42 | 57059ff14d81 |
| 6.11 | 7.1.6 | b82802b5ab26 |
| 6.11 | 7.2 | 2bf282f8f715 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4745-1 | 2026-08-18 | bookworm 6.12.101-1~deb12u1 | tracker |
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:LAttack vector, local
- The vulnerability is triggered entirely through local interfaces — two MGMT_OP_LOAD_CONN_PARAM commands written to a local AF_BLUETOOTH/BTPROTO_HCI socket bound to HCI_CHANNEL_CONTROL, reaching load_conn_param() via hci_sock_sendmsg()/hci_mgmt_cmd(). No over-the-air interaction from a remote Bluetooth peer is required.
- AC:LAttack complexity, low
- The attacker controls both sides of the race: it issues the LOAD_CONN_PARAM that queues conn_update_sync() and then immediately issues a second LOAD_CONN_PARAM whose hci_conn_params_clear_disabled() frees the borrowed entry before hci_cmd_sync_work() dequeues it, and it can grool the slab by repeated hci_conn_params_add() calls.
- PR:LPrivileges required, low
- Reaching load_conn_param() needs a trusted MGMT socket (CAP_NET_ADMIN at bind), which is exactly the privilege held by the unprivileged Bluetooth service account on Android and desktop Linux (bluetoothd / com.android.bluetooth) — a low-privilege, externally exposed daemon, not real root, and the standard scoring for MGMT-socket flaws.
- UI:NUser interaction, none
- Exploitation requires only that the attacker send its own MGMT commands over an existing LE central connection it can itself establish; no action by any other user or victim application is needed.
- S:UScope, unchanged
- The use-after-free corrupts kernel slab memory and its impact stays within the kernel's own security authority; no VM, IOMMU, or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- This is a slab use-after-free read: conn_update_sync() reads addr/addr_type and the four interval fields from a freed hci_conn_params and places them into the HCI_OP_LE_CONN_UPDATE command, leaking reallocated heap contents; more generally a UAF gives the attacker control over freed-object contents and can be leveraged into arbitrary kernel memory disclosure.
- I:HIntegrity impact, high
- The attacker grooms the freed hci_conn_params slot with controlled data, so freed memory dictates which connection is looked up and what parameters are programmed into the controller; a use-after-free of this kind is a standard primitive for heap manipulation and control-flow/data corruption in the kernel.
- A:HAvailability impact, high
- The bug is a confirmed KASAN slab-use-after-free (BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0) in a workqueue context, which panics on KASAN/panic_on_warn kernels and readily causes oopses or unpredictable Bluetooth-stack state otherwise.