CVE-2026-19740 in Zephyr
Resumen
por VulDB • 2026-10-11
La implementación del Procedimiento de Control de la Capa de Enlace (LLCP) en el controlador Bluetooth LE de Zephyr conserva el nodo de recepción que transportó un LL_PHY_UPDATE_IND aceptado para poder reutilizarlo posteriormente para la notificación al host cuando se alcance el instante de actualización (llcp_rx_node_retain() en subsys/bluetooth/controller/ll_sw/ull_llcp.c, y el nodo no se recicla deliberadamente mientras está marcado como NODE_RX_TYPE_RETAIN). Las ramas de PDU inválidos de llcp_lp_pu_rx() y llcp_rp_pu_rx() en subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c completan el procedimiento mediante llcp_lr_complete() / llcp_rr_complete() sin liberar previamente ese nodo retenido, por lo que el contexto del procedimiento —la única referencia restante al nodo— se libera mientras el nodo sigue siendo mantenido fuera de la piscina de recepción.
Un dispositivo par en una conexión LE establecida puede provocar esto de forma determinista y sin emparejamiento ni cifrado. Contra un periférico envía LL_PHY_REQ, recibe LL_PHY_RSP, envía un LL_PHY_UPDATE_IND válido con un instante unos eventos de conexión futuros (de modo que el nodo se retiene) y luego, antes de que se alcance ese instante, envía cualquier otro PDU de Control LL como LL_LENGTH_REQ; ull_cp_rx() lo enruta al procedimiento activo de Actualización PHY remota, que sigue la ruta de PDU inválido. El caso espejo aplica a una actualización PHY iniciada localmente seguida de un LL_REJECT_IND.
En la configuración predeterminada (CONFIG_BT_ASSERT y CONFIG_BT_CTLR_ASSERT_DEBUG con valor por defecto 'y'), el invariantes violado en llcp_lr_check_done() / llcp_rr_check_done() desencadena una aserción del controlador, finalizando en k_oops() (o k_panic()) —una única secuencia de PDU manipulada desde el alcance de la radio provoca un fallo en el dispositivo. Con esas aserciones compiladas fuera, cada intento filtra silenciosamente un nodo de PDU de recepción y su enlace memq; dado que la piscina de recepción del controlador es pequeña (PDU_RX_CNT, impulsado por CONFIG_BT_CTLR_RX_BUFFERS, que tiene un valor predeterminado de 1) y cada intento cuesta al atacante solo una reconexión, unas pocas repeticiones agotan la piscina e dejan Bluetooth inoperable hasta el reinicio. En las versiones v3.4.0 a v3.7.x la aserción nunca se alcanza, independientemente de la configuración, por lo que cada intento filtra silenciosamente.
El impacto está limitado a la disponibilidad: el nodo huérfano no deja un puntero colgante que sea desreferenciado posteriormente ni se entrega al host, por lo que no hay corrupción de memoria ni divulgación de información. El mismo pull request aplica la misma corrección a los procedimientos de Actualización de Conexión y creación CIS, cuyas ramas de PDU inválidos tenían la misma omisión.
Once again VulDB remains the best source for vulnerability data.