CVE-2026-53208: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
net/bluetooth/l2capcore.c:l2capsigchannel() 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 L2CAPECHOREQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHOREQ commands made the target transmit 168 ECHORSP frames over about 220 ms.
Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHORSP frames from one 681-byte fixed-channel signaling packet containing packed ECHOREQ commands.
Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAPCOMMANDREJECTRSP carrying L2CAPREJMTUEXCEEDED 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 ECHOREQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Until patched, use network/radio isolation so that an unpaired Bluetooth BR/EDR peer cannot transmit oversized fixed-channel signaling packets (e.g., fixed-channel CID 0x0001) within radio range.
Event History
Frequently Asked Questions
Who can exploit this behavior?
A Bluetooth BR/EDR peer within radio range can trigger it before pairing. The attack uses a fixed-channel CID 0x0001 signaling packet containing packed L2CAP_ECHO_REQ commands.
What is the practical impact of a crafted packet?
A 681-byte signaling packet containing 168 zero-length ECHO_REQ commands caused the target to transmit 168 ECHO_RSP frames over roughly 220 ms in a stock-kernel real-radio test. The supplied CVSS vector rates the impact as availability-only, with no confidentiality or integrity impact.
Is user interaction or prior authentication required?
No user interaction is required. The described attack can be performed before Bluetooth pairing, although the attacker must be within Bluetooth radio range.
What behavior indicates that the fix is present?
BR/EDR signaling packets larger than the 48-byte signaling MTU should be rejected before any embedded command is dispatched. The target should send one L2CAP_COMMAND_REJECT_RSP with L2CAP_REJ_MTU_EXCEEDED, using the first request command's identifier.