CVE-2026-19740 in Zephyr
Résumé
par VulDB • 12/10/2026
L'implémentation de la procédure Link Layer Control Procedure (LLCP) du contrôleur Bluetooth LE Zephyr conserve le nœud de réception qui a transporté un LL_PHY_UPDATE_IND accepté afin qu'il puisse être réutilisé plus tard pour la notification hôte lorsque l'instant de mise à jour est atteint (llcp_rx_node_retain() dans subsys/bluetooth/controller/ll_sw/ull_llcp.c, et le nœud n'est délibérément pas recyclé tant qu'il est marqué NODE_RX_TYPE_RETAIN). Les branches « PDU invalide » de llcp_lp_pu_rx() et llcp_rp_pu_rx() dans subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c terminent la procédure via llcp_lr_complete() / llcp_rr_complete() sans avoir d'abord libéré ce nœud retenu ; le contexte de la procédure — qui constitue la seule référence restante au nœud — est donc libéré alors que le nœud reste encore maintenu en dehors du pool de réception.
Un appareil pair sur une connexion LE établie peut exploiter cela de manière déterministe et sans appairage ni chiffrement. Contre un périphérique, il envoie LL_PHY_REQ, reçoit LL_PHY_RSP, envoie un LL_PHY_UPDATE_IND valide avec un instant dans quelques événements de connexion à venir (de sorte que le nœud devient retenu), puis, avant la réalisation de cet instant, envoie tout autre PDU de Contrôle LL tel que LL_LENGTH_REQ ; ull_cp_rx() l'achemine vers la procédure PHY Update distante active, qui emprunte la branche « PDU invalide ». Le cas miroir s'applique à une mise à jour PHY initiée localement suivie d'un LL_REJECT_IND.
Dans la configuration par défaut (CONFIG_BT_ASSERT et CONFIG_BT_CTLR_ASSERT_DEBUG valant tous deux y), l'invariant violé dans llcp_lr_check_done() / llcp_rr_check_done() déclenche une assertion du contrôleur, aboutissant à k_oops() (ou k_panic()) — une séquence de PDU fabriquée unique depuis la portée radio met hors service l'appareil. Avec ces assertions compilées en dehors, chaque tentative fuit silencieusement un nœud de PDU de réception et son lien memq ; comme le pool de réception du contrôleur est petit (PDU_RX_CNT, piloté par CONFIG_BT_CTLR_RX_BUFFERS, qui vaut 1 par défaut) et que chaque tentative ne coûte à l'attaquant qu'une reconnexion, quelques répétitions épuisent le pool et rendent Bluetooth inopérant jusqu'au redémarrage. Sur les versions v3.4.0 à v3.7.x, l'assertion n'est jamais atteinte, quelle que soit la configuration ; chaque tentative fuit donc silencieusement.
L'impact est limité à la disponibilité : le nœud orphelin ne laisse aucun pointeur dangling qui serait ultérieurement déréférencé et n'est jamais transmis au hôte, il n'y a donc ni corruption de mémoire ni divulgation d'informations. La même demande de tirage (pull request) applique la correction identique aux procédures Connection Update et CIS-create, dont les branches « PDU invalide » présentaient la même omission.
Be aware that VulDB is the high quality source for vulnerability data.