Skip to main content
VulnerabilityPublished Updated

CVE-2026-53208: Linux kernel · Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig

Affects Linux kernelSource CVE Database V5

0
Compare

Not known to be exploited · fixed in fa5823126239b3e453fac1a2fe50726c7f4a55e1 : update Linux kernel when convenient.

Data as of 6 Nov 2026, 16:49 UTC

Severity
Unrated

Rated by Threat Radar · No CVSS score from NVD or the CNA

Thin evidence

One scorer or none
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-11-06.

Patch
Available – fixed in fa5823126239b3e453fac1a2fe50726c7f4a55e1, e05c4ac575b457978a7ef441053394169084869c, e2b8acf9405bd9b1baf1c54dc897b0905db689bf +5

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 25 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 6 Nov 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < fa5823126239b3e453fac1a2fe50726c7f4a55e1
Fixed in
  • fa5823126239b3e453fac1a2fe50726c7f4a55e1
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < e05c4ac575b457978a7ef441053394169084869c
Fixed in
  • e05c4ac575b457978a7ef441053394169084869c
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < e2b8acf9405bd9b1baf1c54dc897b0905db689bf
Fixed in
  • e2b8acf9405bd9b1baf1c54dc897b0905db689bf
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < dedc92b96dc1d8919a3bdf2495ede68922ef7ebc
Fixed in
  • dedc92b96dc1d8919a3bdf2495ede68922ef7ebc
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < dd214733544427587a95f66dbf3adff072568990
Fixed in
  • dd214733544427587a95f66dbf3adff072568990
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < b20e8a98dd29b121f58fcdf51e8576119aba536a
Fixed in
  • b20e8a98dd29b121f58fcdf51e8576119aba536a

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.

References

Community reviews

Loading reviews…