CVE-2026-10680 in Zephyr
Summary
by MITRE • 07/22/2026
The Classic (BR/EDR) L2CAP signaling handlers l2cap_br_conf_req() and l2cap_br_conf_rsp() in subsys/bluetooth/host/classic/l2cap_br.c validated the minimum command size against buf->len (the bytes remaining in the whole received PDU) instead of len (the per-command data length from the L2CAP signaling header). Because multiple signaling commands can be packed into one PDU, buf->len may exceed a command's len. An attacker can send a CONF_REQ command with a header length smaller than the configuration-request structure (e.g. 0), followed by another command so that buf->len still satisfies the check. The check then passes incorrectly and opt_len = len - sizeof(*req) underflows the uint16_t to a near-0xFFFF value. The configuration-option loop, which lacks an opt_len-versus-buf->len guard, then walks far past the end of the pooled ACL receive buffer using net_buf pull primitives that perform no runtime bounds check, producing an out-of-bounds read of host memory and, when the out-of-bounds option bytes encode an MTU or flush-timeout option, an out-of-bounds write. The BR/EDR signaling channel is processed before pairing/encryption and an L2CAP channel to an L0 service such as SDP can be opened without pairing, so an unauthenticated peer within radio range that can establish an ACL connection can trigger the flaw, leading to memory corruption and denial of service (host/device crash). The defect is present in released versions including v4.4.0. The fix validates against len instead of buf->len in both handlers.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/22/2026
The vulnerability described represents a critical buffer overflow condition within the Bluetooth BR/EDR L2CAP signaling layer of the Zephyr RTOS, specifically affecting the l2cap_br_conf_req() and l2cap_br_conf_rsp() functions located in subsys/bluetooth/host/classic/l2cap_br.c. This flaw stems from improper validation logic where the system checks command size against buf->len, which represents the total bytes remaining in the entire received Protocol Data Unit rather than len, which denotes the per-command data length specified in the L2CAP signaling header. The fundamental issue arises because multiple signaling commands can be packed into a single PDU, creating a scenario where buf->len may legitimately exceed the individual command's len value, yet the validation logic fails to account for this distinction.
The exploitation mechanism leverages the packing capability of L2CAP signaling commands within a single PDU to craft malicious payloads that bypass initial validation checks. An attacker can construct a CONF_REQ command with a header length smaller than the actual configuration-request structure - for instance, setting the header length to zero - followed immediately by another command such that buf->len still meets the minimum size requirement. This incorrect validation allows execution to proceed past the initial bounds check, where the calculation opt_len = len - sizeof(*req) causes an underflow of the uint16_t variable, resulting in a value approaching 0xFFFF. The subsequent configuration-option processing loop lacks proper bounds checking against either opt_len or buf->len, causing it to traverse far beyond the legitimate buffer boundaries using net_buf pull primitives that perform no runtime validation.
This vulnerability manifests through out-of-bounds memory access patterns that can result in both read and write operations beyond allocated buffer limits. The out-of-bounds read exposes sensitive host memory contents to potential disclosure, while the specific scenario involving MTU or flush-timeout options can trigger out-of-bounds writes that corrupt critical data structures within the device's memory space. Given the nature of BR/EDR signaling channel processing, which occurs before pairing and encryption protocols are established, this vulnerability is particularly dangerous as it allows unauthenticated attackers within radio range to exploit the flaw simply by establishing an ACL connection. The attack vector can leverage L2CAP channels to low-level services such as SDP that do not require authentication, making the vulnerability accessible to remote adversaries without requiring any pre-established security context.
The security implications extend beyond simple denial-of-service conditions to potentially enable arbitrary code execution through memory corruption, with the vulnerability present in released versions including v4.4.0 and likely affecting all prior releases. This flaw maps directly to CWE-129, which addresses improper validation of input ranges, and CWE-787, covering out-of-bounds write vulnerabilities. From an ATT&CK framework perspective, this represents a privilege escalation vulnerability through network service exploitation, potentially leading to system compromise via memory corruption techniques that could be leveraged for lateral movement or persistence within affected Bluetooth-enabled devices.
The fix implemented addresses the core validation issue by correcting both l2cap_br_conf_req() and l2cap_br_conf_rsp() handlers to validate against len rather than buf->len, ensuring that command size checks are properly scoped to individual command boundaries rather than aggregate PDU lengths. This change eliminates the underflow condition that previously enabled malicious traversal of buffer limits and prevents both the out-of-bounds read and write operations that could lead to device instability or potential code execution. The remediation approach aligns with defensive programming best practices by ensuring proper bounds checking at the command level rather than allowing aggregate PDU validation to mask individual command integrity issues.