CVE-2026-53208
Received Received - Intake
Bluetooth BR/EDR Signaling MTU Exceeded in Linux Kernel

Publication date: 2026-06-25

Last updated on: 2026-06-25

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-25
Last Modified
2026-06-25
Generated
2026-06-25
AI Q&A
2026-06-25
EPSS Evaluated
N/A
NVD
CVE-2026-53208
EUVD
EUVD-2026-39299
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's Bluetooth L2CAP implementation. Specifically, the function l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a signaling packet larger than the allowed MTUsig containing many L2CAP_ECHO_REQ commands before pairing.

Because of this, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands can cause the target device to transmit 168 ECHO_RSP frames in response, potentially over about 220 milliseconds.

The fix involves defining the BR/EDR signaling MTU as the specification minimum of 48 bytes and rejecting any larger signaling packet with a L2CAP_COMMAND_REJECT_RSP response before processing any commands.

Impact Analysis

An attacker with Bluetooth BR/EDR capability within radio range can exploit this vulnerability to force the target device to send a large number of ECHO_RSP frames by sending a single oversized signaling packet containing many ECHO_REQ commands.

This could lead to resource exhaustion on the target device, potentially causing performance degradation or denial of service conditions due to the processing and transmission of excessive response frames.

Mitigation Strategies

The vulnerability is resolved by enforcing the Bluetooth BR/EDR signaling MTU to the specification minimum of 48 bytes and rejecting any larger signaling packet with an L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched.

Therefore, immediate mitigation involves updating the Linux kernel to a version that includes this fix, which rejects oversized BR/EDR signaling packets and prevents the vulnerability from being exploited.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-53208. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart