CVE-2026-53208

What the bug is

net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.

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.

include/net/bluetooth/l2cap.h
net/bluetooth/l2cap_core.c

What this is

BLUETOOTH SUBSYSTEMMAINTAINERS section matched on include/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 bluetooth

Prints 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-06-25 (4 months ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.12%, higher than 2.0% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

include/net

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
2.6.12	5.10.259	e05c4ac575b4
2.6.12	5.15.210	fa5823126239
2.6.12	6.1.176	b20e8a98dd29
2.6.12	6.6.143	214a2042b16b
2.6.12	6.12.94	a8335f3db15b
2.6.12	6.18.36	dedc92b96dc1
2.6.12	7.0.13	e2b8acf9405b
2.6.12	7.1	dd2147335444

Debian advisories