Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-10680

CVE-2026-10680: Bluetooth L2CAP DOS Vulnerability

CVE-2026-10680 is a denial of service flaw in Bluetooth BR/EDR L2CAP signaling that allows unauthenticated attackers to crash devices via memory corruption. This post covers technical details, affected versions, and mitigations.

Published:

CVE-2026-10680 Overview

CVE-2026-10680 is an out-of-bounds read and write vulnerability in the Zephyr real-time operating system's Bluetooth Classic (BR/EDR) L2CAP signaling layer. The flaw resides in l2cap_br_conf_req() and l2cap_br_conf_rsp() handlers within subsys/bluetooth/host/classic/l2cap_br.c. The handlers validate command size against buf->len instead of the per-command len field, allowing an integer underflow that drives an unbounded parsing loop over host memory. An unauthenticated attacker within Bluetooth radio range can trigger memory corruption and crash the device. The defect is present in released versions including v4.4.0.

Critical Impact

An unauthenticated peer within radio range can trigger memory corruption and denial of service against Zephyr-based devices exposing BR/EDR L2CAP, without requiring pairing or encryption.

Affected Products

  • Zephyr RTOS v4.4.0 and earlier releases containing the vulnerable l2cap_br.c handlers
  • Devices exposing Bluetooth Classic (BR/EDR) L2CAP signaling with services such as SDP reachable pre-pairing
  • Embedded and IoT products built on Zephyr with Bluetooth Classic enabled

Discovery Timeline

  • 2026-07-21 - CVE-2026-10680 published to NVD
  • 2026-07-22 - Last updated in NVD database

Technical Details for CVE-2026-10680

Vulnerability Analysis

The vulnerability [CWE-125] arises from incorrect length validation in Zephyr's Bluetooth Classic L2CAP signaling channel. Multiple signaling commands can be packed into a single Protocol Data Unit (PDU). The handlers check the minimum command size against buf->len, which represents the total remaining bytes in the PDU, rather than against len, the per-command data length extracted from the L2CAP signaling header.

An attacker crafts a CONF_REQ command whose header length is smaller than the configuration-request structure, such as zero, and appends another command so the aggregate PDU size still passes the check. The computation opt_len = len - sizeof(*req) then underflows a uint16_t to a value near 0xFFFF. The configuration-option parsing loop lacks a guard comparing opt_len against buf->len and walks far past the pooled ACL receive buffer using net_buf pull primitives that perform no runtime bounds checks.

Root Cause

The root cause is the use of buf->len in place of len when validating the minimum command size in l2cap_br_conf_req() and l2cap_br_conf_rsp(). This validation error enables an integer underflow that turns option parsing into an unbounded read/write of host memory.

Attack Vector

The BR/EDR signaling channel is processed before pairing and encryption. An L2CAP channel to an L0 service such as Service Discovery Protocol (SDP) can be opened without pairing. Any unauthenticated peer within radio range that can establish an Asynchronous Connection-Less (ACL) link can send the malformed signaling PDU. When the out-of-bounds option bytes decode as an MTU or flush-timeout option, the parser also performs an out-of-bounds write, extending impact beyond information disclosure to memory corruption and host or device crash.

c
// Patch from subsys/bluetooth/host/classic/l2cap_br.c
 	struct bt_l2cap_br_chan *br_chan;
 	int err;
 
-	if (buf->len < sizeof(*rsp)) {
+	if (len < sizeof(*rsp)) {
 		LOG_ERR("Too small L2CAP conf rsp packet size");
 		return;
 	}

Source: Zephyr commit 1d451683. The fix validates against the per-command len field from the signaling header rather than the whole PDU length.

Detection Methods for CVE-2026-10680

Indicators of Compromise

  • Unexpected device reboots or kernel panics on Zephyr targets shortly after receiving Bluetooth Classic connection attempts from nearby peers
  • HCI or Bluetooth controller logs showing malformed L2CAP CONF_REQ or CONF_RSP packets with header length fields smaller than the L2CAP configuration structure
  • ACL connections from unknown Bluetooth device addresses immediately followed by device crashes without pairing having completed

Detection Strategies

  • Capture Bluetooth traffic with btmon or an over-the-air sniffer and flag L2CAP signaling PDUs where the command-header len value is less than sizeof(bt_l2cap_conf_req) or sizeof(bt_l2cap_conf_rsp)
  • Alert on multiple signaling commands packed in a single PDU where the first command's declared length is zero or otherwise inconsistent with its payload
  • Correlate ACL connection events from unpaired peers with subsequent device restarts across a fleet of Zephyr-based endpoints

Monitoring Recommendations

  • Forward Bluetooth stack logs and device crash telemetry from Zephyr devices into a centralized log store for anomaly review
  • Monitor Bluetooth pairing and connection attempts near critical devices and baseline the expected peer inventory
  • Track firmware versions across deployed devices to identify systems still running Zephyr v4.4.0 or earlier releases containing the vulnerable handlers

How to Mitigate CVE-2026-10680

Immediate Actions Required

  • Apply upstream commit 1d451683377f4c8e56d7718565bea7b5c1155159 from the Zephyr project to subsys/bluetooth/host/classic/l2cap_br.c and rebuild firmware for affected devices
  • Inventory all deployed Zephyr-based products with Bluetooth Classic enabled and prioritize patching those exposing SDP or other pre-pairing L2CAP services
  • Restrict physical proximity or radio exposure of vulnerable devices until patched firmware is deployed

Patch Information

The fix is available in the Zephyr project via commit 1d451683 and documented in GitHub Security Advisory GHSA-vrwx-p97q-8854. The patch changes the length validation in both l2cap_br_conf_req() and l2cap_br_conf_rsp() to compare against the per-command len field from the signaling header instead of buf->len.

Workarounds

  • Disable Bluetooth Classic (BR/EDR) support in the Zephyr build configuration if the product only requires Bluetooth Low Energy
  • Disable or restrict pre-pairing L2CAP services such as SDP where the product's use case allows
  • Where feasible, place devices in non-discoverable and non-connectable modes to reduce exposure to unauthenticated peers within radio range
bash
# Zephyr Kconfig - disable Bluetooth Classic if not required
CONFIG_BT_CLASSIC=n
CONFIG_BT_BREDR=n

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.