CVE-2026-10651: Zephyr Bluetooth SDP Parser Buffer Over-Read Vulnerability

Technical summary

The vulnerability exists in bt_sdp_parse_attribute() within Zephyr's Bluetooth Classic SDP parser. The function checks that buf->len >= 3 (ensuring a type-marker byte and 2-byte attribute ID are present), but then unconditionally calls net_buf_simple_pull_u8() to read the data-element descriptor (type field). The pull_u8() macro dereferences the buffer pointer before its only guard, an __ASSERT_NO_MSG() that is compiled out when CONFIG_ASSERT is disabled—the default in production builds. An SDP record of exactly 3 bytes (0x09 plus 2 attribute-ID bytes) will cause a 1-byte out-of-bounds read. The read value is then used as a length selector in subsequent parsing, but malformed records are rejected before any data leakage. The vulnerability is reachable remotely: inbound SDP discovery responses from a Bluetooth peer are parsed directly via public APIs (bt_sdp_get_attr(), bt_sdp_has_attr(), bt_sdp_record_parse()) without prior validation.

Business impact

Devices running Zephyr 4.3.0 or 4.4.0 in a Bluetooth-enabled IoT or embedded application could experience unplanned downtime if an attacker within Bluetooth range triggers a denial of service. The risk is highest in production deployments with CONFIG_ASSERT disabled, where the parser may dereference invalid memory; assertion-enabled builds will panic loudly and may aid debugging but also enable a visible attack vector. For most mainstream applications, the practical window for exploitation is narrow (requires the record to align with a memory boundary or a specific heap layout), making this a medium-urgency patch rather than a critical emergency. However, any device that cannot tolerate unexpected resets should treat this as a priority.

Affected systems

Zephyr Project versions 4.3.0 and 4.4.0 are confirmed affected. The flaw is in the Bluetooth Classic subsystem's SDP parser (subsys/bluetooth/host/classic/sdp.c), so only devices with Bluetooth BR/EDR enabled and the SDP client role active are at risk. This includes various embedded systems, wearables, and IoT gateways that rely on Zephyr for Bluetooth connectivity. Verify your device's exact Zephyr version and Bluetooth configuration in your firmware image or device manifest.

Exploitability

Exploitability is low to moderate despite the high CVSS score, because the impact is constrained. Triggering the vulnerability requires (1) proximity or an established Bluetooth connection, (2) the ability to act as or relay an SDP server, (3) crafting an SDP response with a record of exactly 3 bytes, and (4) the recipient's memory layout must be such that the out-of-bounds byte either corrupts a meaningful target or lands at an unmapped page (to cause a fault). In practice, the attacker has no control over the data returned by the over-read, so information disclosure is not feasible. Denial of service is achievable under specific conditions, but requires some trial or luck to trigger reliably. No public exploit code or proof-of-concept is known to be in active circulation.

Remediation

Upgrade to a patched version of Zephyr (4.4.1 or later, or a backport to 4.3.x) that includes the fix: adding sizeof(type) to the length check in bt_sdp_parse_attribute(). Before applying patches, confirm your current Zephyr version and rebuild your firmware. If an immediate upgrade is not feasible, disable Bluetooth SDP client functionality or restrict Bluetooth peer connectivity to trusted devices only. Verify the patch in the official Zephyr repository or release notes before deployment.

Patch guidance

The fix modifies the initial bounds check from buf->len < 3 to buf->len < (3 + sizeof(type)), ensuring the parser does not attempt to read the type field unless it is actually present in the buffer. Patch Zephyr by pulling the latest commit from the main branch or waiting for a minor release (e.g., 4.4.1, 4.3.1) that includes the fix. Rebuild and test your firmware in a controlled environment before rolling out to production. If your organization maintains a custom fork of Zephyr, backport the commit using the Zephyr project's official guidance; verify against the vendor advisory for the exact commit hash.

Detection guidance

Look for Zephyr firmware builds with versions 4.3.0 or 4.4.0 in your inventory. Enable CONFIG_ASSERT in test and staging environments to catch the panic condition and observe its symptoms. Monitor for unexpected device reboots or bluetooth-related crashes in production logs, especially if they correlate with new or unusual Bluetooth peer connections. Network-level detection is difficult because the malformed SDP record is brief and indistinguishable from noise without deep packet inspection; focus on host-based indicators (core dumps, crash logs, watchdog resets).

Why prioritize this

This vulnerability scores 7.1 (HIGH) due to its remote triggering vector and availability impact, but real-world severity is tempered by the narrow exploitation window and lack of confidentiality or integrity risk. Prioritize patching if your Zephyr deployment handles critical functions (medical devices, safety-critical systems, high-availability IoT infrastructure) or if you cannot tolerate unexpected resets. If your devices use Zephyr but do not enable Bluetooth SDP, or if they operate in tightly controlled Bluetooth environments with only trusted peers, you can defer patching to a routine maintenance window. Organizations with strict change-control processes should still schedule the update within 2–4 weeks.

Risk score, explained

The CVSS 3.1 score of 7.1 (HIGH, AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H) reflects a low attack complexity, no privilege or user interaction required, and adjacent-network attack scope. The 'C:L' (low confidentiality impact) acknowledges the theoretical over-read of one byte, though in practice the byte is not leaked. The 'A:H' (high availability impact) captures the denial-of-service risk. However, the actual exploitability is constrained by memory layout and the requirement for specific record alignment, so treat the score as an upper bound; real risk in your environment depends on your threat model and the reliability requirements of your devices.

Frequently asked questions