CVE-2026-53208

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig

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.