Description

The Link Layer Control Procedure (LLCP) implementation of the Zephyr software Bluetooth LE Controller retains the receive node that carried an accepted LL_PHY_UPDATE_IND so that it can later be reused for the host notification when the update instant is reached (llcp_rx_node_retain() in subsys/bluetooth/controller/ll_sw/ull_llcp.c, and the node is deliberately not recycled while marked NODE_RX_TYPE_RETAIN). The invalid-PDU arms of llcp_lp_pu_rx() and llcp_rp_pu_rx() in subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c completed the procedure via llcp_lr_complete() / llcp_rr_complete() without first releasing that retained node, so the procedure context — the only remaining reference to the node — was freed while the node was still held out of the receive pool. A peer device on an established LE connection can drive this deterministically and without pairing or encryption. Against a peripheral it sends LL_PHY_REQ, receives LL_PHY_RSP, sends a valid LL_PHY_UPDATE_IND with an instant a few connection events in the future (so the node becomes retained), and then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ; ull_cp_rx() routes it to the active remote PHY Update procedure, which takes the invalid-PDU path. The mirror case applies to a locally initiated PHY Update followed by an LL_REJECT_IND. In the default configuration (CONFIG_BT_ASSERT and CONFIG_BT_CTLR_ASSERT_DEBUG both default y) the violated invariant in llcp_lr_check_done() / llcp_rr_check_done() triggers a controller assertion, ending in k_oops() (or k_panic()) — a single crafted PDU sequence from radio range faults the device. With those assertions compiled out, each attempt silently leaks one receive PDU node and its memq link; because the controller receive pool is small (PDU_RX_CNT, driven by CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1) and each attempt costs the attacker only a reconnect, a few repetitions exhaust the pool and leave Bluetooth inoperable until reboot. On releases v3.4.0 through v3.7.x the assertion is never reached, whatever the configuration, so every attempt leaks silently. The impact is limited to availability: the orphaned node leaves no dangling pointer that is later dereferenced and is never delivered to the host, so there is no memory corruption or information disclosure. The same pull request applies the identical release to the Connection Update and CIS-create procedures, whose invalid-PDU arms had the same omission.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-10-11T18:16:59.290Z",
  "pubdate": "2026-10-11T18:16:59.290Z",
  "executiveSummary": "The Zephyr Bluetooth LE Controller contains a resource exhaustion vulnerability within its Link Layer Control Procedure (LLCP) implementation. The flaw occurs due to a failure to release receive nodes during specific invalid Protocol Data Unit (PDU) handling paths, leading to memory leaks within the controller's receive buffer pool.\nThe vulnerability allows an unauthenticated remote attacker within radio range to trigger a Denial of Service (DoS) condition by repeatedly sending crafted PDU sequences. This interaction effectively exhausts the limited PDU_RX_CNT memory pool, rendering the Bluetooth functionality inoperable until the device is rebooted.\nAffected versions include Zephyr releases v3.4.0 through v3.7.x. While earlier versions may trigger controller assertions (k_oops/k_panic) depending on configuration, newer versions experience silent depletion of the receive buffer pool.\nThe impact is strictly limited to availability, as there is no evidence of memory corruption, code execution, or unauthorized information disclosure. Exploitation requires only an established LE connection and does not necessitate pairing or encryption, making it a significant risk for devices relying on continuous Bluetooth connectivity.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper management of receive node memory within the LLCP stack, specifically regarding how PDU nodes are handled during PHY Update, Connection Update, and CIS-create procedures.\nDuring a PHY Update procedure, the Zephyr Bluetooth LE Controller executes llcp_rx_node_retain() in subsys/bluetooth/controller/ll_sw/ull_llcp.c to hold a received LL_PHY_UPDATE_IND PDU. This node is marked as NODE_RX_TYPE_RETAIN to ensure it remains available for host notification once the update instant is reached. However, if an invalid PDU is received while the procedure is active (e.g., an LL_LENGTH_REQ during a PHY Update), the logic routes execution to the invalid-PDU arms in llcp_lp_pu_rx() or llcp_rp_pu_rx() located in subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c. These functions invoke completion handlers (llcp_lr_complete() / llcp_rr_complete()) without explicitly releasing the previously retained receive node.\nBecause the procedure context acts as the sole reference to the retained node, freeing the context results in the node being orphaned. The node remains held out of the receive pool but is never processed or returned to the free list, creating a permanent memory leak for that specific buffer.\nThe attack flow is deterministic and does not require elevated privileges or authentication. An attacker initiates an LE connection and performs a sequence of control PDUs to force the controller into the vulnerable state: 1) Send LL_PHY_REQ. 2) Receive LL_PHY_RSP. 3) Send a valid LL_PHY_UPDATE_IND with a future instant. 4) Send a conflicting PDU (e.g., LL_LENGTH_REQ or LL_REJECT_IND) before the instant is reached. This forces the state machine into the incomplete cleanup path.\nIn environments where CONFIG_BT_ASSERT is enabled, the resulting invariant violation leads to a system panic. In configurations where assertions are disabled, or in versions v3.4.0 through v3.7.x where the assertion check is not reached, the system silently leaks a buffer. Given that the default configuration for PDU_RX_CNT (controlled by CONFIG_BT_CTLR_RX_BUFFERS) is often set to a small integer (typically 1), a low number of connection attempts by an attacker will exhaust the buffer pool. Once the pool is depleted, the controller can no longer accept new PDUs, effectively causing a total loss of Bluetooth availability."
}