Look up another CVE · open CVE-2026-74540 in the interactive tracker
CVE-2026-74540
Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp
Published 2026-08-15 (2 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-74540 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-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6466-1 · 2026-08-25 · text | 6.12.105-1 | Update the kernel and reboot. DSA-6466-1 shipped the fix on 2026-08-25, in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.8-1 | Update the kernel and reboot. Fixed in 7.1.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers.
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/l2cap_core.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-15 (2 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 15.9% 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.14 | 5.10.265 | 15d6c2367217 |
| 3.14 | 5.15.216 | 1818180fe12d |
| 3.14 | 6.1.183 | 8325eafb38c3 |
| 3.14 | 6.6.151 | fd4c1e301bde |
| 3.14 | 6.12.103 | 522b730c62c5 |
| 3.14 | 6.18.44 | 58e3c5289ad2 |
| 3.14 | 7.1.8 | 09f447accc25 |
| 3.14 | 7.2 | c4740e7f23ff |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| DSA-6466-1 | 2026-08-25 | trixie 6.12.105-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
- The vulnerability is reached when the kernel processes an incoming L2CAP LE Connect Response over an established Bluetooth LE ACL link (HCI ACL receive → l2cap_recv_acldata → l2cap_le_sig_channel → l2cap_le_connect_rsp), requiring radio proximity rather than routable Internet access.
- AC:LAttack complexity, low
- The remote Bluetooth peer controls both sides of the race by sending L2CAP_LE_CONN_RSP while concurrently triggering channel teardown via L2CAP DISCONN_REQ or HCI disconnect, freeing the channel between __l2cap_get_chan_by_ident() and l2cap_chan_lock() without attacker-uncontrollable timing.
- PR:NPrivileges required, none
- No local privileges on the victim are required; exploitation needs only a nearby attacker with an established LE Bluetooth connection sending crafted L2CAP signaling packets, with no root, CAP_NET_ADMIN, or user-namespace capability on the target host.
- UI:NUser interaction, none
- On phones, wearables, automotive, and IoT deployments, paired or background Bluetooth clients routinely auto-initiate L2CAP credit-based connections without per-attack user confirmation once an LE link is up, enabling trigger of the pending outgoing connect path.
- S:UScope, unchanged
- Impact is confined to kernel memory and privileges on the Bluetooth-connected host; there is no VM guest-to-host escape, sandbox breakout, or IOMMU/DMA boundary crossing, so security scope remains unchanged per kernel CVSS guidance.
- C:HConfidentiality impact, high
- Use-after-free of heap-allocated struct l2cap_chan allows attacker-controlled reuse of freed slab memory, enabling disclosure of kernel heap contents and pointers through corrupted channel fields accessed after premature free.
- I:HIntegrity impact, high
- The UAF window writes channel state (ident, dcid, mtu, credits) and invokes chan->ops function pointers (ready, teardown) on freed memory, enabling heap spraying and control-flow hijack for arbitrary kernel code execution.
- A:HAvailability impact, high
- Operating on a freed l2cap_chan can immediately kernel-oops or panic from corrupt mutex/state during lock/unlock and callback dispatch; UAF in softirq L2CAP processing inherently threatens full system availability.