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.
// 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
# 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.

