In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig… (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.
AI Analysis
Technical Summary
The Linux kernel's Bluetooth L2CAP signaling parser in net/bluetooth/l2cap_core.c did not enforce the signaling MTU (MTUsig) limit, accepting BR/EDR signaling packets up to the channel MTU. This allowed a Bluetooth BR/EDR peer to send a fixed-channel CID 0x0001 packet larger than MTUsig containing many L2CAP_ECHO_REQ commands before pairing. In practice, one 681-byte packet with 168 zero-length ECHO_REQ commands caused the target to transmit 168 ECHO_RSP frames over about 220 ms, leading to a potential denial of service. The fix defines the signaling MTU as the spec minimum of 48 bytes and rejects any larger signaling packet with an L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before dispatching any command. The Linux implementation intentionally deviates from the Bluetooth Core spec by always emitting one reject response with the identifier from the first command header to avoid peer desynchronization. This vulnerability traces back to the initial git import of the Bluetooth code with no prior fix.
Potential Impact
A Bluetooth BR/EDR peer within radio range can send a single oversized signaling packet containing many L2CAP_ECHO_REQ commands before pairing, causing the target device to respond with a large number of ECHO_RSP frames. This can lead to a denial of service condition by consuming device resources and radio airtime. There is no impact on confidentiality or integrity. The vulnerability requires local radio range access and low privileges (PR:L).
Mitigation Recommendations
A fix for this vulnerability is available in the Linux kernel that enforces the signaling MTU limit and rejects oversized BR/EDR signaling packets with an appropriate L2CAP command reject response before processing any commands. Users and administrators should apply the official Linux kernel updates that include this fix. Since this is a kernel-level Bluetooth vulnerability, no additional mitigations are indicated beyond applying the patch. Patch status is not explicitly confirmed in the provided data; check the vendor advisory or Linux kernel release notes for the exact fixed versions and update accordingly.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig… (CVE-2026-53208)
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 v3.1
Score 5.5medium
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel's Bluetooth L2CAP signaling parser in net/bluetooth/l2cap_core.c did not enforce the signaling MTU (MTUsig) limit, accepting BR/EDR signaling packets up to the channel MTU. This allowed a Bluetooth BR/EDR peer to send a fixed-channel CID 0x0001 packet larger than MTUsig containing many L2CAP_ECHO_REQ commands before pairing. In practice, one 681-byte packet with 168 zero-length ECHO_REQ commands caused the target to transmit 168 ECHO_RSP frames over about 220 ms, leading to a potential denial of service. The fix defines the signaling MTU as the spec minimum of 48 bytes and rejects any larger signaling packet with an L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before dispatching any command. The Linux implementation intentionally deviates from the Bluetooth Core spec by always emitting one reject response with the identifier from the first command header to avoid peer desynchronization. This vulnerability traces back to the initial git import of the Bluetooth code with no prior fix.
Potential Impact
A Bluetooth BR/EDR peer within radio range can send a single oversized signaling packet containing many L2CAP_ECHO_REQ commands before pairing, causing the target device to respond with a large number of ECHO_RSP frames. This can lead to a denial of service condition by consuming device resources and radio airtime. There is no impact on confidentiality or integrity. The vulnerability requires local radio range access and low privileges (PR:L).
Mitigation Recommendations
A fix for this vulnerability is available in the Linux kernel that enforces the signaling MTU limit and rejects oversized BR/EDR signaling packets with an appropriate L2CAP command reject response before processing any commands. Users and administrators should apply the official Linux kernel updates that include this fix. Since this is a kernel-level Bluetooth vulnerability, no additional mitigations are indicated beyond applying the patch. Patch status is not explicitly confirmed in the provided data; check the vendor advisory or Linux kernel release notes for the exact fixed versions and update accordingly.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-hhxp-r7j7-v7jv
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-53208"]
- Ecosystems
- []
- Database Specific Severity
- MODERATE
- Cvss Version
- 3.1
Threat ID: 6a46eca927e9c7971943a6d3
Added to database: 07/02/2026, 22:56:41 UTC
Last enriched: 07/02/2026, 23:02:43 UTC
Last updated: 07/31/2026, 19:24:47 UTC
Views: 4
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.