CVE-2026-98432: regla de nftables para Ubuntu 24.04, probada

Ubuntu 24.04 aún no tiene kernel corregido para el CVE-2026-98432, un fallo de TCP sobre IPv4 con puntuación 9,8. Red Hat propone una regla de nftables que descarta los paquetes TCP con opciones IP. La probé en un espacio de red aislado: frena un SYN con opciones y deja pasar a curl. Ayuda, pero no sustituye al parche.

Lo Probado es del 2 de noviembre de 2026, en un Ubuntu 24.04, dentro de un espacio de red nuevo que desaparece al terminar. Lo de Ubuntu, Red Hat, CIQ y Anthropic es Revisado: leído en sus páginas, no ejecutado (así distingo ambas cosas).

Qué ha pasado y qué dice cada fuente

El fallo está en cómo el kernel guarda las opciones IP durante el saludo TCP. Según la ficha de Ubuntu, que cita el CVE, el socket hijo hereda esas opciones sin copiarlas y se liberan con kfree() mientras otro procesador aún las lee. El arreglo es liberarlas con kfree_rcu().

Las fechas no coinciden y conviene decirlo:

• 15 de octubre: publicación del CVE, según Ubuntu y CIQ.
• 27 de octubre: Anthropic cuenta un exploit contra servidores con un oyente de Multipath TCP (MPTCP) que ejecuta órdenes como root.
• 30 de octubre: boletín RHSB-2026-016 de Red Hat, el de la regla. Por eso es actualidad hoy.

No todos lo ven igual. Según CIQ, el equipo de Go dice que el fallo no es propio de MPTCP. La puntuación upstream es 8,1, con complejidad alta, frente al 9,8 del CNA del kernel.

Red Hat habla de un atacante remoto sin credenciales que debe acertar con el momento de sus peticiones. No sé cuánta de esa distancia es teoría y cuánta práctica, y no voy a dar detalles de explotación.

Cómo saber si tu Ubuntu ya trae el arreglo

En la ficha de Ubuntu, el paquete linux figura como «vulnerable, en trabajo» en la 22.04 (5.15.0-203.213), la 24.04 (6.8.0-149.149) y la 26.04 (7.0.0-43.43). Ese número es la versión en la que trabaja Ubuntu, no una corregida. La orden que responde por tu máquina es esta:

# Solo mira: con --dry-run no instala nada
pro fix CVE-2026-98432 --dry-run

# Qué kernel tienes y cuál ofrece apt
uname -r
apt-cache policy linux-image-generic | head -3

Hoy, 2 de noviembre, pro fix imprime el texto del CVE y termina con «A fix is coming soon. Try again tomorrow» y «CVE-2026-98432 is not resolved». Cuando salga el kernel, dirá lo contrario y apt ofrecerá una versión nueva.

Antes probé el changelog del paquete con grep, y no sirve: el de Ubuntu no cita los CVE, así que daba 0 con cualquier número.

Apagar MPTCP no basta

Apagar solo MPTCP no basta. CIQ avisa de que, con MPTCP apagado, el TCP normal sigue llegando al código afectado. Yo comprobé solo lo que hace el interruptor: con net.mptcp.enabled=1 se crea un socket de protocolo 262; con 0, el sistema responde «Protocol not available».

La regla de Red Hat, probada

Los paquetes TCP normales llevan una cabecera IP de 5 palabras de 32 bits (20 bytes). La regla descarta los que traen más, es decir, los que llevan opciones IP. Es el fichero del boletín de Red Hat, sin cambios:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

# Comprobar la sintaxis, cargar y ver el contador
sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

# Quitarla cuando el kernel esté corregido
sudo nft delete table inet cve_2026_98432

En la prueba, un oyente en 127.0.0.1 recibió dos clientes: uno normal y otro que fija 4 bytes de opciones IP (tres «no operación» y un fin de lista). Sin la regla, los dos conectaron al instante.

Con ella, el normal conectó y el de opciones agotó los 3 segundos. El contador marcó 3 paquetes y 192 bytes descartados (el SYN y dos reintentos). Con la tabla borrada, el cliente de opciones volvió a conectar.

Los clientes de todos los días no lo notan: tres peticiones con curl y una con urllib de Python contra un servidor HTTP local devolvieron 200 con la regla cargada, y el contador siguió en 0. Una curiosidad: nft list muestra la prioridad -310 como raw - 10, porque raw equivale a -300.

Lo que la regla no arregla

Red Hat lo dice claro: la regla «reduce la exposición» pero no la elimina, puede romper cargas que necesiten opciones IP y no sustituye al parche. CIQ añade que no probó IPv6, fragmentos ni contenedores. Yo tampoco.

La mía usa el gancho input, así que solo ve el tráfico dirigido al propio equipo. CIQ pone la suya en prerouting, con otro nombre y otra prioridad.

Mi lectura

Mi lectura, que es opinión: la regla compra tiempo en un servidor que escucha en internet y que no puedes reiniciar hoy, y no más. Si ya has pasado por Vghost o por el bloqueo de algif_aead, ya conoces el patrón: Ubuntu publica el kernel después, y los cortafuegos y bloqueos de módulos cubren el hueco.

Vuelta atrás y lo que no he probado

Mis pruebas no dejaron nada: el espacio de red y la tabla desaparecieron al salir de unshare, y el interruptor de MPTCP que moví era el de ese espacio, no el del sistema. En un servidor real, la vuelta atrás es la orden nft delete table de arriba.

• Que la regla sobreviva a un reinicio: Red Hat solo da la carga manual, y no he probado ninguna forma de dejarla fija.
• El fallo en sí, ni el efecto de la regla sobre un ataque real: no hay nada de eso aquí.
• IPv6, fragmentos, contenedores y tráfico reenviado.
• Aplicaciones que usen opciones IP a propósito, como las de seguridad etiquetada (CIPSO).

Pendiente: cuando Ubuntu publique el kernel corregido para la 24.04, lo apunto aquí con la fecha y la versión. Entonces la regla sobra: actualiza, reinicia y bórrala. La foto de portada es de unos conmutadores Ethernet de 19 pulgadas con paneles de conexión (CC BY-SA 4.0, vía Wikimedia Commons); no es mi equipo.