Look up another CVE · open CVE-2026-63976 in the interactive tracker
CVE-2026-63976
Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success
Published 2026-07-19 (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-63976 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 | fixed | 6.1.176-1 | Update the kernel and reboot. Fixed in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| 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
l2cap_ecred_reconf_rsp() returns early on success without clearing chan->ident. Every other L2CAP response handler (l2cap_ecred_conn_rsp, l2cap_le_connect_rsp, l2cap_config_rsp) clears chan->ident after a successful transaction to prevent the channel from matching subsequent responses with the recycled ident value. A remote attacker that completed a reconfiguration as the peer can replay a failure response with the stale ident, causing the kernel to match and destroy the already-established channel via l2cap_chan_del(chan, ECONNRESET). Clear chan->ident for all matching channels on success, and harden the failure path by using l2cap_chan_hold_unless_zero() consistent with other L2CAP handlers (l2cap_le_command_rej, __l2cap_get_chan_by_ident).
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
- 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.46%, higher than 38.1% 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 |
|---|---|---|
| 5.7 | 5.10.259 | 59f5ecf6ad5c |
| 5.7 | 5.15.210 | ae0152d77d10 |
| 5.7 | 6.1.176 | c2afd2613fda |
| 5.7 | 6.6.143 | cc2b4f749de0 |
| 5.7 | 6.12.93 | 3b5b5f423b4f |
| 5.7 | 6.18.35 | f39049304ba6 |
| 5.7 | 7.0.12 | 8e7977afaef3 |
| 5.7 | 7.1 | 00e1950716c6 |
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 reached by sending crafted L2CAP ECRED reconfiguration responses over an established Bluetooth Low Energy ACL connection (HCI ACL → L2CAP LE signaling channel), which requires proximity on the same Bluetooth radio segment.
- AC:LAttack complexity, low
- Once a BLE ECRED session exists, the remote peer fully controls signaling traffic and can reliably complete a reconfiguration handshake and then replay a failure response with the stale identifier; no special victim state or memory layout is required beyond an active connection.
- PR:NPrivileges required, none
- Exploitation requires only the ability to act as a remote Bluetooth peer sending L2CAP signaling packets; no local shell access, capabilities, or root privileges on the victim host are needed.
- UI:NUser interaction, none
- No victim user action beyond having Bluetooth enabled and an attacker-established BLE connection is required; the attacker can inject the malicious L2CAP_ECRED_RECONF_RSP frames programmatically without user interaction.
- S:UScope, unchanged
- The impact is confined to the kernel Bluetooth/L2CAP security authority on the victim host and does not cross a VM, sandbox, or IOMMU boundary.
- C:HConfidentiality impact, high
- The uncleorrected failure path used unsafe refcounting on matched channels, and stale-identifier matching during concurrent teardown can produce use-after-free conditions that are exploitable for kernel memory disclosure. The uncorrected failure path used unsafe refcounting on matched channels, and stale-identifier matching during concurrent teardown can produce use-after-free conditions that are exploitable for kernel memory disclosure.
- I:HIntegrity impact, high
- Erroneous `l2cap_chan_del()` on live channels corrupts kernel connection state, and the associated refcount/UAF race on the failure path can be leveraged for heap manipulation and potential arbitrary kernel write or code execution.
- A:HAvailability impact, high
- A remote attacker can repeatedly force teardown of established ECRED L2CAP channels (denying Bluetooth services on phones, automotive, IoT, and embedded systems), and the underlying refcount bug can also trigger kernel crashes.