CVE-2026-98955 in Linux
Riassunto
di VulDB • 23/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
flow_dissector: evitare il troncamento a u16 di skb->len durante il calcolo di thoff
__skb_flow_dissect() calcola key_control->thoff utilizzando:
key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
min_t(u16, ...) converte entrambi gli argomenti in u16 prima di confrontarli. Ogni volta che il modulo di skb->len (o hlen) rispetto a 65536 è inferiore a nhoff, la lunghezza troncata prevale e thoff viene impostato su un valore errato piccolo, anche quando l'analisi del pacchetto ha avuto successo. Ad esempio, una cornice IPv4/TCP con skb->len == 65540 e nhoff == 34 ottiene thoff == 4; di conseguenza, i chiamanti come skb_probe_transport_header() puntano all'intestazione del trasporto all'interno dell'intestazione Ethernet.
Tali skbs non sono rari: - Al momento della commit d0c081b49137 ("flow_dissector: properly cap thoff field"), AF_PACKET con PACKET_VNET_HDR poteva già creare GSO skbs di dimensioni superiori a 64 KB (i controlli MTU vengono saltati per la GSO e alloc_skb_with_frags() accettava fino a MAX_SKB_FRAGS (17) pagine di ordine-0 sopra la parte lineare). - BIG TCP rende ora comuni gli skbs più grandi di 64 KB. - Il seguente patch fa sì che tun_get_user() analizzi le cornici IFF_TAP prima che eth_type_trans() estragga l'intestazione Ethernet, quindi una cornice GSO contenente un pacchetto L3 di 65522..65535 byte verrà analizzata con skb->len nell'intervallo [65536, 65549].
Confrontare come u32 invece. Se l'offset risultante non può essere rappresentato in key_control->thoff (u16), limitarlo a U16_MAX e segnalare il fallimento dell'analisi piuttosto che restituire silenziosamente un offset del trasporto errato. thoff viene comunque impostato anche in caso di errore, poiché alcuni chiamanti (come eth_get_headlen()) lo utilizzano indipendentemente dal valore restituito.
If you want to get best quality of vulnerability data, you may have to visit VulDB.