Description

The Bluetooth Link Layer Control Procedure (LLCP) implementation for Connected Isochronous Stream (CIS) creation retains an RX node (ctx->node_ref.rx, marked NODE_RX_TYPE_RETAIN) so it can later be reused as the host notification — on the peripheral while awaiting the Host's reply to an LL_CIS_REQ, and on the central for the whole duration of a locally initiated CIS Create. In subsys/bluetooth/controller/ll_sw/ull_llcp_cc.c, the "invalid PDU received" paths of llcp_rp_cc_rx() and llcp_lp_cc_rx() terminated the connection and completed the procedure without releasing that retained node, breaking the invariant checked in llcp_lr_check_done() and llcp_rr_check_done() and orphaning the node's memory. A peer device within radio range can reach this with a single extra LL Control PDU on an unauthenticated, unencrypted ACL link. Against a peripheral, the attacker sends a valid LL_CIS_REQ and then, before the Host replies, any unrelated LL Control PDU (for example LL_VERSION_IND), which ull_cp_rx() routes into the active remote procedure. Against a central performing a CIS Create, a malicious peripheral answers with LL_UNKNOWN_RSP for CIS_REQ, which is dispatched into the active local procedure. No pairing, encryption or user interaction is required; the code is compiled in when CONFIG_BT_CTLR_PERIPHERAL_ISO or CONFIG_BT_CTLR_CENTRAL_ISO is enabled. In default builds (CONFIG_BT_CTLR_ASSERT_DEBUG is default y) the retained-node assertion fires immediately, producing a controller fatal error and, typically, a system reset from one injected PDU. With the development assertions disabled, each attempt permanently loses one node from the controller's small LL notification pool (LL_PDU_RX_CNT, 2 * CONFIG_BT_CTLR_LLCP_CONN) together with its memq_link_t; repeating the connect-attack-reconnect cycle exhausts the pool, after which notification allocation always fails, RX flow control stalls, and the non-disableable LL_ASSERT_ERR() in llcp_lp_cc_flush() faults. The impact is limited to availability — the leaked node is orphaned, never reused or double-freed — and recovery requires a reboot.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-10-11T18:16:59.050Z",
  "pubdate": "2026-10-11T18:16:59.050Z",
  "executiveSummary": "A memory leak vulnerability exists in the Bluetooth Link Layer Control Procedure (LLCP) implementation for Connected Isochronous Stream (CIS) creation within the controller stack.\nThe vulnerability is triggered by an improper handling of retained RX nodes during specific 'invalid PDU received' error paths in the LLCP state machine.\nThe impact ranges from remote denial-of-service (DoS) through system crashes via assertion failures to permanent resource exhaustion of the controller's notification pool.\nThe vulnerability affects systems where CONFIG_BT_CTLR_PERIPHERAL_ISO or CONFIG_BT_CTLR_CENTRAL_ISO are enabled.\nExploitation is trivial for a nearby attacker, requiring no authentication, encryption, or user interaction.\nBy repeatedly injecting malformed LL control PDUs, an attacker can leak memory nodes, leading to RX flow control stalls and inevitable controller fatal errors.\nThe risk is categorized as high for availability, as the attack can be executed remotely over-the-air, resulting in a persistent denial of service that requires a physical system reboot.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper management of RX nodes within subsys/bluetooth/controller/ll_sw/ull_llcp_cc.c. The Bluetooth controller retains an RX node (ctx->node_ref.rx) with the NODE_RX_TYPE_RETAIN flag to facilitate host notifications during CIS creation procedures. However, the logic within llcp_rp_cc_rx() and llcp_lp_cc_rx() fails to release this retained node when handling invalid PDU scenarios.\nSpecifically, when an unexpected or invalid LL control PDU is processed while a CIS creation is in progress, the connection is terminated and the procedure is completed without explicitly freeing the retained RX node. This violates the memory management invariants enforced by llcp_lr_check_done() and llcp_rr_check_done(), resulting in an orphaned node and its associated memq_link_t structure.\nThe attack flow leverages the Bluetooth controller's interaction with peers. Against a peripheral, an attacker initiates a valid LL_CIS_REQ and follows it with an unrelated LL control PDU (e.g., LL_VERSION_IND) before the Host responds. The controller’s ull_cp_rx() function dispatches this secondary PDU into the active procedure, triggering the flawed error handling path. Against a central, a malicious peripheral can respond to an LL_CIS_REQ with an LL_UNKNOWN_RSP, which similarly triggers the faulty code path.\nThe impact is twofold based on build configuration. In default configurations where CONFIG_BT_CTLR_ASSERT_DEBUG is enabled, the mismatch between the state and the retained node causes a fatal assertion failure, resulting in an immediate system reset upon the injection of a single crafted PDU. In production builds where assertions are disabled, the system silently leaks memory. Because the controller maintains a fixed, finite pool of notification nodes (defined by LL_PDU_RX_CNT), an attacker can perform a connect-attack-reconnect cycle to systematically exhaust the pool.\nOnce the pool is exhausted, notification allocation fails, causing the RX flow control to stall. Eventually, the non-disableable LL_ASSERT_ERR() in llcp_lp_cc_flush() will trigger, resulting in a persistent controller fault. This vulnerability effectively allows an unauthenticated remote attacker to cause a reliable and repeatable denial-of-service condition, rendering the Bluetooth interface non-functional until a device reboot is performed."
}