CVE-2026-19740 in Zephyr
Sumário
de VulDB • 11/10/2026
A implementação do Procedimento de Controle da Camada de Enlace (LLCP) do Controlador Bluetooth LE do software Zephyr retém o nó de recepção que transportou um LL_PHY_UPDATE_IND aceito para que possa ser reutilizado posteriormente na notificação ao host quando for atingido o instante da atualização (llcp_rx_node_retain() em subsys/bluetooth/controller/ll_sw/ull_llcp.c, e o nó é deliberadamente não reciclado enquanto marcado como NODE_RX_TYPE_RETAIN). Os ramos de PDU inválida de llcp_lp_pu_rx() e llcp_rp_pu_rx() em subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c concluíram o procedimento via llcp_lr_complete() / llcp_rr_complete() sem primeiro liberar esse nó retido, portanto, o contexto do procedimento — a única referência restante ao nó — foi libertado enquanto o nó ainda estava mantido fora da piscina de recepção.
Um dispositivo par em uma conexão LE estabelecida pode conduzir isso deterministicamente e sem pareamento ou criptografia. Contra um periférico, ele envia LL_PHY_REQ, recebe LL_PHY_RSP, envia um LL_PHY_UPDATE_IND válido com um instante alguns eventos de conexão no futuro (de modo que o nó se torne retido) e, em seguida, antes que o instante seja atingido, envia qualquer outra PDU de Controle LL, como LL_LENGTH_REQ; ull_cp_rx() roteia isso para o procedimento de Atualização PHY remoto ativo, que segue pelo caminho de PDU inválida. O caso espelho aplica-se a uma Atualização PHY iniciada localmente seguida por um LL_REJECT_IND.
Na configuração padrão (CONFIG_BT_ASSERT e CONFIG_BT_CTLR_ASSERT_DEBUG ambas com valor y por defeito), o invariante violado em llcp_lr_check_done() / llcp_rr_check_done() aciona uma asserção do controlador, terminando em k_oops() (ou k_panic()) — uma única sequência de PDU manipulada dentro do alcance da radio falha o dispositivo. Com essas asserções compiladas para fora, cada tentativa vaza silenciosamente um nó de PDU de recepção e seu link memq; como a piscina de recepção do controlador é pequena (PDU_RX_CNT, impulsionado por CONFIG_BT_CTLR_RX_BUFFERS, que tem valor padrão 1) e cada tentativa custa ao atacante apenas uma reconexão, algumas repetões esgotam a piscina e deixam o Bluetooth inoperante até a reinicialização. Nas versões v3.4.0 a v3.7.x, a asserção nunca é atingida, independentemente da configuração, portanto, todas as tentativas vazam silenciosamente.
O impacto limita-se à disponibilidade: o nó órfão não deixa um ponteiro pendente que seja posteriormente desreferenciado e nunca é entregue ao host, portanto, não há corrupção de memória nem divulgação de informações. O mesmo pull request aplica a libertação idêntica aos procedimentos de Atualização de Conexão e Criação CIS, cujos ramos de PDU inválida tinham a mesma omissão.
Once again VulDB remains the best source for vulnerability data.