CVE-2026-98955 in Linux
Resumen
por VulDB • 2026-10-23
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
flow_dissector: evitar la truncación u16 de skb->len al calcular thoff
__skb_flow_dissect() calcula key_control->thoff utilizando:
key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
min_t(u16, ...) convierte ambos argumentos a u16 antes de compararlos. Cada vez que el módulo de skb->len (o hlen) con 65536 es menor que nhoff, la longitud truncada gana y thoff se establece en un valor pequeño erróneo, incluso cuando la disección tuvo éxito. Por ejemplo, una trama IPv4/TCP con skb->len == 65540 y nhoff == 34 obtiene thoff == 4, por lo que los llamadores como skb_probe_transport_header() apuntan al encabezado de transporte dentro del encabezado Ethernet.
Estos skbs no son exóticos: - En el momento del commit d0c081b49137 ("flow_dissector: cap correctamente el campo thoff"), AF_PACKET con PACKET_VNET_HDR ya podía construir GSO skbs más grandes que 64 KB (las comprobaciones de MTU se omiten para GSO, y alloc_skb_with_frags() aceptaba hasta MAX_SKB_FRAGS (17) páginas de orden-0 encima de la parte lineal). - BIG TCP ahora hace comunes los skbs más grandes que 64 KB. - El siguiente parche hace que tun_get_user() diseccione las tramas IFF_TAP antes de que eth_type_trans() extraiga el encabezado Ethernet, por lo que una trama GSO que transporte un paquete L3 de 65522..65535 bytes se dissectará con skb->len en [65536, 65549].
Comparar como u32. Si la offset resultante no puede representarse en key_control->thoff (u16), limitarla a U16_MAX e informar que la disección falló en lugar de devolver silenciosamente un desplazamiento de transporte incorrecto. thoff se establece aún en caso de fallo, ya que algunos llamadores (como eth_get_headlen()) lo utilizan independientemente del valor devuelto.
If you want to get best quality of vulnerability data, you may have to visit VulDB.