Look up another CVE · open CVE-2026-64408 in the interactive tracker
CVE-2026-64408
Bluetooth: bnep: pin L2CAP connection during netdev registration
Published 2026-07-25 (3 months ago) by the Linux kernel CNA. Subsystem net/bluetooth. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-64408 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 | fixedDLA-4720-1 · 2026-08-05 · text | 6.1.180-1 | Update the kernel and reboot. DLA-4720-1 shipped the fix on 2026-08-05, in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.96-1 | Update the kernel and reboot. Fixed in 6.12.96-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.4-1 | Update the kernel and reboot. Fixed in 7.1.4-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.4-1 | Update the kernel and reboot. Fixed in 7.1.4-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4724-1 · 2026-08-07 · text | 6.12.100-1~deb12u1 | Update the kernel and reboot. DLA-4724-1 shipped the fix on 2026-08-07, in 6.12.100-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
bnep_add_connection() reads the L2CAP connection without holding the channel lock, then passes its HCI device to register_netdev(). Controller teardown can clear and release that connection concurrently, leaving the network device registration path to dereference a freed parent device. Take a reference to the L2CAP connection while holding the channel lock. Retain it until register_netdev() has taken the parent device reference.
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/bnep/core.c
- What this is
- BLUETOOTH SUBSYSTEMMAINTAINERS section matched on net/bluetooth/ · linux-bluetooth@vger.kernel.org · Supported
- Kernel module
- bnep
Check it on the machine
grep -wE 'CONFIG_BT|CONFIG_BT_BNEP' /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 bnepPrints 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 switches
- CONFIG_BT, CONFIG_BT_BNEP
- Reads as
- all on means the file is compiled; any one off means it is not.
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-25 (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.26%, higher than 16.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- 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 |
|---|---|---|
| 3.13 | 5.10.261 | 390b5db3ff87 |
| 3.13 | 5.15.212 | 46a88784c4c9 |
| 3.13 | 6.1.178 | 551ae773ec64 |
| 3.13 | 6.6.145 | ae215c5b6422 |
| 3.13 | 6.12.96 | df22adc7eafc |
| 3.13 | 6.18.39 | a6b22dbd8092 |
| 3.13 | 7.1.4 | 563a85730471 |
| 3.13 | 7.2 | bb067a99a035 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4724-1 | 2026-08-07 | bookworm 6.12.100-1~deb12u1 | tracker |
| DLA-4723-1 | 2026-08-07 | bullseye 6.1.180-1~deb11u1 | tracker |
| DLA-4720-1 | 2026-08-05 | bookworm 6.1.180-1 | tracker |
| DLA-4717-1 | 2026-08-05 | bullseye 5.10.262-1 | 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:AAttack vector, adjacent network
- An adjacent Bluetooth peer can initiate a BNEP/PAN connection that causes privileged bluetoothd to issue BNEPCONNADD, then tear down the ACL link during netdev registration. Exploitation therefore requires Bluetooth radio adjacency.
- AC:LAttack complexity, low
- The peer controls both the connection setup that triggers the ioctl and the competing disconnect, and can repeat attempts until the lifetime window is hit. No condition beyond the attacker's practical control is required.
- PR:NPrivileges required, none
- The adjacent peer needs no Linux credentials or capabilities because root bluetoothd performs the CAP_NET_ADMIN ioctl on its behalf in an enabled, auto-authorized PAN deployment. The direct ioctl requires CAP_NET_ADMIN in the initial user namespace, but the adjacent path does not.
- UI:NUser interaction, none
- An enabled PAN service can automatically accept or pre-authorize connections, after which setup and teardown require no victim action. Prior service configuration is not user interaction during exploitation.
- S:UScope, unchanged
- The memory corruption occurs in the host kernel and compromises resources governed by that same kernel security authority. It does not cross a VM, IOMMU, or comparable security boundary.
- C:HConfidentiality impact, high
- The stale parent points into a freed hci_conn allocation, and reclaiming that use-after-free object can enable disclosure of arbitrary kernel memory. Confidentiality impact is therefore High.
- I:HIntegrity impact, high
- device_add() calls get_device() on the freed parent, producing a refcount write into reclaimed memory and potentially further device-list corruption. The use-after-free can support arbitrary kernel-memory corruption or control-flow hijacking.
- A:HAvailability impact, high
- The use-after-free can cause a kernel oops, panic, or corrupted device hierarchy during netdev registration. An adjacent peer can repeatedly initiate and terminate connections to crash the system.