CVE-2026-12236 in Zephyr
Summary
by MITRE • 08/13/2026
The Bluetooth host GATT client function parse_read_std_char_desc() in subsys/bluetooth/host/gatt.c parses an ATT Read By Type Response received from a remote GATT server during BT_GATT_DISCOVER_STD_CHAR_DESC discovery. The per-entry stride rsp->len is taken directly from the peer's PDU, and the parse loop both tests its exit condition (length >= rsp->len) and advances (length -= rsp->len, pdu += rsp->len) using that value. The minimum value of rsp->len was never validated before the loop.
A malicious or malfunctioning peer can reply with rsp->len = 0. Because length is unsigned and never decreases, the loop condition stays true forever and the read pointer never advances; as long as the body is at least a few bytes with a non-zero handle and a matching descriptor UUID, the host repeatedly re-parses the same bytes and invokes the discovery callback, never terminating. This hangs the Bluetooth host processing thread (CWE-835, loop with unreachable exit condition).
The condition is reachable by any connected peer once the local device initiates standard-descriptor-value discovery; GATT discovery does not require bonding or encryption, so an unauthenticated adjacent attacker that the device connects to can trigger it. The impact is denial of service of the Bluetooth subsystem (and likely a watchdog reset on constrained targets); there is no memory disclosure or corruption.
The fix adds a rsp->len < sizeof(struct bt_att_data) check before the loop, rejecting under-length responses so the stride is always non-zero and the loop terminates. The sibling parsers parse_include() and parse_characteristic() already validated rsp->len and are unaffected.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/13/2026
The vulnerability described in this CVE involves a critical flaw in the Bluetooth host implementation within the Bluetooth GATT client functionality. The issue exists in the parse_read_std_char_desc() function located in subsys/bluetooth/host/gatt.c, which processes ATT Read By Type Responses during standard characteristic descriptor discovery operations. This function handles communication with remote GATT servers during the BT_GATT_DISCOVER_STD_CHAR_DESC process where the local device queries for standard characteristic descriptors. The flaw stems from inadequate validation of the response packet structure before processing, creating a dangerous condition that can lead to indefinite loop execution.
The technical implementation problem manifests through improper handling of the response length parameter rsp->len which is directly extracted from the peer's Protocol Data Unit without sufficient validation. During the parsing loop, both the exit condition and the advancement mechanism rely entirely on this unvalidated length value. When a malicious or malfunctioning peer sends a response with rsp->len = 0, the unsigned integer comparison creates an infinite loop scenario where the loop condition length >= rsp->len remains perpetually true. This occurs because the length variable never decreases due to the zero stride value, causing the read pointer to remain stationary while repeatedly processing identical data segments.
The operational impact of this vulnerability extends beyond simple resource consumption to potentially cause complete system disruption. The infinite loop effectively hangs the Bluetooth host processing thread, which represents a denial of service condition that can severely compromise device functionality. On constrained embedded systems, this hanging behavior may trigger watchdog resets, leading to complete system failure. This vulnerability affects any connected peer that initiates standard descriptor value discovery, making it particularly dangerous since GATT discovery operations do not require authentication or encryption. The attack vector only requires proximity and successful connection establishment, allowing unauthenticated adjacent attackers to exploit this condition.
The vulnerability aligns with CWE-835 which specifically addresses "Loop with Unreachable Exit Condition" and demonstrates how improper input validation can create exploitable conditions in embedded systems. From an ATT&CK framework perspective, this represents a denial of service attack technique that targets system stability and availability rather than data confidentiality or integrity. The fix implemented involves adding a minimum length validation check rsp->len < sizeof(struct bt_att_data) before entering the parsing loop, ensuring that the stride value is always non-zero and allowing proper loop termination. This defensive programming approach mirrors existing patterns found in sibling functions like parse_include() and parse_characteristic() which already include appropriate response length validations, demonstrating established best practices for robust protocol implementation in embedded Bluetooth systems.
The security implications of this vulnerability extend to device reliability and availability in scenarios where Bluetooth connectivity is critical for system operation. While the flaw does not enable memory corruption or data disclosure, its potential for causing complete system hang represents a significant risk in embedded devices where watchdog timeouts may be insufficient to recover from such conditions. The vulnerability demonstrates how seemingly minor validation gaps in protocol parsing can create substantial operational risks in real-world deployments, particularly in IoT devices and mobile platforms where Bluetooth functionality is integral to core device operations.