CVE-2026-19740
Beschrijving NL
De implementatie van de Link Layer Control Procedure (LLCP) van de Zephyr-software Bluetooth LE Controller behoudt het ontvangstknooppunt dat een geaccepteerde LL_PHY_UPDATE_IND droeg, zodat het later kan worden hergebruikt voor de hostmelding wanneer het updatemoment wordt bereikt (llcp_rx_node_retain() in subsys/bluetooth/controller/ll_sw/ull_llcp.c, en het knooppunt wordt opzettelijk niet gerecycled terwijl het is gemarkeerd als NODE_RX_type_RETAIN). De ongeldige-PDU-armen van llcp_lp_pu_rx() en llcp_rp_pu_rx() in subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c voltooiden de procedure via llcp_lr_complete() /llcp_rr_complete() zonder eerst dat behouden knooppunt vrij te geven, zodat de procedurecontext — de enige overgebleven verwijzing naar het knooppunt — werd vrijgegeven terwijl het knooppunt nog steeds uit de ontvangstpool werd gehouden. Een peer-apparaat op een gevestigde LE-verbinding kan dit deterministisch en zonder koppeling of codering aansturen. Tegen een randapparaat verzendt het LL_PHY_req, ontvangt LL_PHY_RSP, verzendt een geldige LL_PHY_update_IND met een paar verbindingsgebeurtenissen in de toekomst (zodat het knooppunt wordt behouden) en verzendt vervolgens, voordat het moment is bereikt, een andere LL Control PDU zoals LL_LENGTH_req; ull_cp_rx() naar de actieve externe PHY Update-procedure, die het ongeldige-PDU-pad neemt. De spiegelkast is van toepassing op een lokaal geïnitieerde PHY-update, gevolgd door een LL_REJECT_IND. In de standaardconfiguratie (CONFIG_BT_ASSERT en CONFIG_BT_CTLR_ASSERT_DEBUG beide standaard y) activeert de geschonden invariant in llcp_lr_check_done() /llcp_rr_check_done() een controllerbevestiging, eindigend op k_oops() (of k_panic()) — een enkele vervaardigde PDU-sequentie van radiofrequentiestoringen van het apparaat. Met die beweringen die zijn samengesteld, lekt elke poging stilletjes één PDU-knooppunt en zijn memq-link; omdat de ontvangende pool van de controller klein is (PDU_RX_CNT, aangedreven door CONFIG_BT_CTLR_RX_BUFFERS, die standaard op 1 staat) en elke poging kost de aanvaller slechts een herverbinding, een paar herhalingen putten de pool uit en laten Bluetooth onbruikbaar totdat deze opnieuw wordt opgestart. Bij releases v3.4.0 tot en met v3.7.x wordt de bewering nooit bereikt, ongeacht de configuratie, dus elke poging lekt geruisloos. De impact is beperkt tot beschikbaarheid: het verweesde knooppunt laat geen bungelende aanwijzer achter die later wordt verwijderd en nooit aan de host wordt geleverd, dus er is geen geheugenbeschadiging of openbaarmaking van informatie. Hetzelfde pull-verzoek past dezelfde release toe op de Connection Update- en CIS-create-procedures, waarvan de ongeldige-PDU-armen dezelfde omissie hadden.
Origineel (Engels) tonen
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.