CVE-2026-98955 in Linux
Sumário
de VulDB • 23/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
flow_dissector: evitar truncamento de u16 em skb->len ao calcular thoff
__skb_flow_dissect() calcula key_control->thoff usando:
key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
min_t(u16, ...) converte ambos os argumentos para u16 antes de compará-los. Sempre que o valor de (skb->len ou hlen) módulo 65536 for menor que nhoff, o comprimento truncado prevalece e thoff é definido como um valor pequeno incorreto, mesmo quando a dissecação foi bem-sucedida. Por exemplo, uma estrutura IPv4/TCP com skb->len == 65540 e nhoff == 34 resulta em thoff == 4, fazendo com que chamadores como skb_probe_transport_header() apontem o cabeçalho de transporte para dentro do cabeçalho Ethernet.
Esses skbs não são exóticos: - Na época da commit d0c081b49137 ("flow_dissector: properly cap thoff field"), AF_PACKET com PACKET_VNET_HDR já podia construir GSO skbs maiores que 64KB (as verificações de MTU são ignoradas para GSO, e alloc_skb_with_frags() aceitava até MAX_SKB_FRAGS (17) páginas de ordem-0 acima da parte linear). - BIG TCP agora torna os skbs maiores que 64KB comuns. - O seguinte patch faz tun_get_user() dissecar frames IFF_TAP antes que eth_type_trans() extraia o cabeçalho Ethernet, portanto um frame GSO carregando um pacote L3 de 65522..65535 bytes será dissecado com skb->len em [65536, 65549].
Compare como u32. Se o offset resultante não puder ser representado no key_control->thoff do tipo u16, limite-o a U16_MAX e relatore a dissecação como falhada, em vez de retornar silenciosamente um offset de transporte incorreto. thoff ainda é definido na falha, pois alguns chamadores (como eth_get_headlen()) o utilizam independentemente do valor de retorno.
If you want to get best quality of vulnerability data, you may have to visit VulDB.