CVE-2026-14697 in Zephyr
Sumário
de VulDB • 31/08/2026
A função `net_ipv6_send_ns()` em `subsys/net/ip/ipv6_nbr.c` aloca um `net_pkt` de transmissão para uma Solicitação de Vizinho (Neighbor Solicitation). Quando é chamada com um pacote de dados pendente em um vizinho não resolvido e a fila pendente (`pending_queue`) desse vizinho já está não vazia (ou seja, há uma NS já pendente), a função anexa o pacote de dados e retorna antecipadamente sem jamais enviar a NS via `net_send_data()` ou liberá-la com `net_pkt_unref()`. O novo `net_pkt` da NS alocado e seus buffers TX associados ficam retidos apenas por uma variável local, sendo vazados permanentemente, nunca retornando ao pool de contagem definido por `CONFIG_NET_PKT_TX_COUNT` / `CONFIG_NET_BUF_TX_COUNT`.
O ramo com vazamento situa-se no caminho normal de transmissão IPv6: `net_ipv6_prepare_for_send()` (chamada a partir de `net_if.c`) invoca `net_ipv6_send_ns()` para qualquer pacote IPv6 de saída ou encaminhado cujo próximo salto ainda não esteja no cache de vizinhos. Um atacante on-link (adjacente) pode acionar isso deterministicamente enviando uma rajada de pacotes de solicitação (por exemplo, solicitações eco ICMPv6 ou datagramas UDP) que falsificam um único endereço de origem inexistente na mesma rede local: o nó gera uma resposta para cada um; a primeira resposta enfileira uma NS e todas as respostas subsequentes durante a janela de resolução INCOMPLETE de aproximadamente três segundos seguem pelo ramo com vazamento, perdendo-se um pacote TX. Nós configurados como roteadores que encaminham tráfego do atacante em direção a um host inexistente na mesma rede local também sofrem o mesmo tipo de vazamento.
Como os pacotes vazados nunca são recuperados e `CONFIG_NET_PKT_TX_COUNT` tem valor padrão apenas 4 (14 para Ethernet), uma rajada breve de baixa taxa esgota o pool TX. Uma vez exaurido, o nó não pode mais alocar nenhum pacote de transmissão e não consegue enviar TCP/UDP, ARP/ND ou qualquer resposta, produzindo um negação de serviço em rede completa e persistente que não se recupera sozinha até uma reinicialização. A correção libera o pacote NS não enviado com `net_pkt_unref(pkt)` antes do retorno antecipado.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.