Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-13T18:17:17.017Z",
  "pubdate": "2026-08-13T18:17:17.017Z",
  "executiveSummary": "A vulnerability exists within the Bluetooth host GATT client implementation, specifically in the parse_read_std_char_desc() function located in subsys/bluetooth/host/gatt.c.\nClassified as CWE-835 (Loop with Unreachable Exit Condition), this vulnerability arises from a failure to validate the minimum value of the per-entry stride rsp->len received in an ATT Read By Type Response from a remote GATT server.\nAn unauthenticated adjacent attacker with the ability to connect to the target device can exploit this flaw by supplying an invalid stride length of zero during the BT_GATT_DISCOVER_STD_CHAR_DESC discovery procedure.\nExploitation causes the parsing loop to execute indefinitely without advancing the read pointer, resulting in a complete denial of service of the Bluetooth subsystem and frequently triggering a watchdog reset on constrained target devices.\nNo memory corruption or information disclosure occurs as a result of this vulnerability.\nPrerequisites for exploitation include an active connection and the initiation of standard-descriptor-value discovery by the local device; neither bonding nor encryption is required.",
  "technicalDetails": "The vulnerable component is the Bluetooth host GATT client parsing function parse_read_std_char_desc() residing in subsys/bluetooth/host/gatt.c.\nThe root cause of the vulnerability is the lack of input validation regarding the per-entry stride value rsp->len obtained directly from the peer's Protocol Data Unit (PDU) during an ATT Read By Type Response.\nIn the affected parsing loop, the exit condition (length >= rsp->len) and the pointer/length advancement logic (length -= rsp->len, pdu += rsp->len) rely entirely on the provided rsp->len value.\nWhen a malicious or malfunctioning peer transmits an ATT Read By Type Response containing a stride length of zero (rsp->len = 0), the loop variable tracking remaining length does not decrease, and the internal buffer read pointer fails to advance.\nIf the PDU body contains at least a few bytes with a non-zero handle and a matching descriptor UUID, the condition remains true infinitely.\nConsequently, the Bluetooth host processing thread continuously re-parses the exact same bytes and repeatedly invokes the discovery callback without ever terminating.\nThe attack flow proceeds as follows: First, an unauthenticated attacker establishes a connection with the target device. Second, the local device initiates standard-descriptor-value discovery (BT_GATT_DISCOVER_STD_CHAR_DESC), which does not require authentication or encryption. Third, the attacker responds to the discovery request with a crafted ATT Read By Type Response where rsp->len is set to zero. Fourth, the vulnerable parse_read_std_char_desc() function enters the unconstrained parsing loop.\nThis behavior leads directly to a denial of service by hanging the Bluetooth host processing thread, which typically triggers a hardware or software watchdog reset on resource-constrained embedded targets.\nSibling parser functions within the same subsystem, namely parse_include() and parse_characteristic(), correctly implement validation checks on rsp->len and are therefore unaffected."
}