Look up another CVE · open CVE-2026-90256 in the interactive tracker
CVE-2026-90256
Bluetooth: L2CAP: use proto_lock for l2cap_data to fix l2cap_disconn_ind
Published 2026-09-17 (31 days 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-90256 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 | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
hci_conn::l2cap_data is accessed without locks in l2cap_disconn_ind via hci_conn_timeout (disc_work) -> hci_proto_disconn_ind -> l2cap_disconn_ind. This is UAF if the l2cap_conn is deleted concurrently. disc_work is disabled sync in hci_conn_del(), so we cannot take hci_dev_lock in disc_work. Fix by using proto_lock to guard l2cap_data, in addition to hdev->lock which is held in other access paths.
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-09-17 (31 days 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.34%, higher than 26.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.14 | 7.2.6 | b495a3a9b33b |
| 6.14 | 7.3 | 2b66c83ff175 |
| 6.6.84 | 0 | 0 |
| 6.12.20 | 0 | 0 |
| 6.13.8 | 0 | 0 |
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
- l2cap_disconn_ind() is reached from hci_conn_timeout() (hci_conn.disc_work) via hci_proto_disconn_ind() only for ACL_LINK/LE_LINK; hcon->l2cap_data is installed by l2cap_conn_add() from l2cap_connect_cfm()/l2cap_chan_connect() on that HCI connection, so the triggering peer must be in Bluetooth radio range.
- AC:LAttack complexity, low
- The attacker creates the ACL/LE link so l2cap_conn_add() publishes hcon->l2cap_data, then tears it down so l2cap_conn_del() or the last l2cap_conn_put() from l2cap_chan_destroy() (rfcomm_process_rx on rfcomm_run) frees the object while hci_conn_timeout() reads conn->disc_reason; both sides are attacker-driven and retryable.
- PR:NPrivileges required, none
- HCI Connection Complete delivers l2cap_connect_cfm() → l2cap_conn_add() and later disc_work with no host uid or capability check; SDP (PSM 0x0001) and RFCOMM session close on remote disconnect likewise need no pairing, so an unauthenticated Bluetooth peer is enough.
- UI:NUser interaction, none
- hci_conn_timeout() runs from hdev->workqueue after the last hci_conn_drop() once the adapter is powered and connectable; incoming ACL/LE setup, RFCOMM/L2CAP teardown, and the disconnect timer need no per-attack user click.
- S:UScope, unchanged
- The UAF is of the host kmalloc l2cap_conn used by l2cap_disconn_ind() and only corrupts that kernel's Bluetooth/HCI state, with no VM, IOMMU, or sandbox boundary crossing.
- C:HConfidentiality impact, high
- l2cap_disconn_ind() locklessly loads hcon->l2cap_data and reads conn->disc_reason after l2cap_conn_free() has kfree'd the kmalloc-1k object, so a sprayed replacement discloses kernel heap contents through that dangling pointer.
- I:HIntegrity impact, high
- The same freed l2cap_conn can be reallocated under attacker control while hci_conn_timeout() still holds the pointer; heap UAF of this object enables spraying and write/control-flow hijack, and the stale disc_reason is consumed as the HCI abort reason.
- A:HAvailability impact, high
- The syzbot report is a slab-use-after-free read of conn->disc_reason in l2cap_disconn_ind() from the hci_conn_timeout worker, which oopses or panics the kernel when the freed l2cap_conn slab is touched.