La vulnerabilidad CVE-2026-98432 en la pila de red IPv4 TCP del kernel de Linux permite a un atacante remoto no autenticado lograr la ejecución de código arbitrario mediante una condición de carrera al procesar conexiones TCP. El problema afecta a todas las versiones del kernel desde la 4.4 e impacta a cualquier sistema con un puerto TCP abierto que acepte conexiones IPv4. Red Hat y Canonical clasifican la vulnerabilidad como crítica con una puntuación CVSS 9.8. Los parches ya están disponibles para RHEL, Amazon Linux y parcialmente para Ubuntu; los administradores deben actualizar el kernel y reiniciar los sistemas.
Esencia técnica de la vulnerabilidad
El problema pertenece a la clase use-after-free y se produce en la función tcp_v4_syn_recv_sock(). Al aceptar una conexión TCP IPv4 entrante, el kernel pasa las opciones IP desde el socket de solicitud al socket hijo sin copiarlas. Si el cliente vuelve a enviar un paquete SYN mientras otro procesador aún está leyendo estas opciones, el kernel accede a memoria ya liberada en la función ip_options_build(). Los sockets TCP hijo no tienen el flag SOCK_RCU_FREE, y el destructor inet_sock_destruct() libera inet_opt con un kfree() normal en lugar de kfree_rcu().
El atacante inicia la condición de carrera enviando solicitudes TCP de conexión con opciones IPv4 Record Route o Timestamp a cualquier puerto TCP en escucha. No se requiere autenticación. Existe un problema similar al migrar sockets de solicitud (net.ipv4.tcp_migrate_req=1). Según los datos de Canonical, IPv6 no es vulnerable al problema principal, ya que la ruta de procesamiento de IPv6 duplica las opciones.
La corrección consiste en sustituir kfree() por kfree_rcu() en inet_sock_destruct() y tcp_v4_reqsk_destructor(), lo que garantiza que la memoria solo se libere tras completarse el RCU grace period.
Discrepancias en la evaluación de la gravedad
Es significativo que los proveedores discrepen en la valoración de la criticidad. Fortinet, Red Hat y Ubuntu asignan CVSSv3 9.8 y estado Critical, señalando la posibilidad de ejecución remota de código. Amazon Linux, por el contrario, valora la vulnerabilidad en 8.1 (Important), haciendo hincapié en la denegación de servicio y la posible corrupción de memoria como consecuencias principales. Esta discrepancia refleja una diferencia en la evaluación de la explotabilidad práctica: la condición de carrera requiere un timing preciso, y no todos los proveedores consideran garantizado lograr una RCE fiable.
Estado de explotación
Según Fortinet, no se ha detectado explotación activa de la vulnerabilidad. Canonical indica que, aparte de la investigación interna de Anthropic, no se conocen otros exploits. En GitHub se ha publicado código que demuestra la condición de carrera y detecta el acceso a memoria liberada en el SYN-ACK, pero sin implementación de ejecución de código. Ya hemos escrito sobre cómo el modelo de investigación interno de Anthropic creó un exploit funcional para esta vulnerabilidad, que permite obtener acceso root en servidores con un listener MPTCP sin autenticación. El código del exploit no se ha publicado.
Sistemas afectados y parches disponibles
La vulnerabilidad afecta a una amplia gama de distribuciones Linux:
- Red Hat Enterprise Linux 8, 9, 10 y Red Hat OpenShift Container Platform: los parches se publicaron el 1 de noviembre (RHSA-2026:93414, RHSA-2026:93412, RHSA-2026:93413). Red Hat también señala que los productos basados en el kernel de RHEL, incluidos Red Hat OpenStack Platform y Red Hat Virtualization, pueden verse afectados.
- Ubuntu 22.04, 24.04, 26.04 LTS: las correcciones están disponibles en el canal -proposed (versiones de kernel 5.15.0-203.213, 6.8.0-149.149, 7.0.0-43.43 respectivamente). Los paquetes de -proposed no se instalan automáticamente. Ubuntu 26.10 está corregido en el canal principal. Para Ubuntu 20.04 y anteriores todavía no hay parches.
- Amazon Linux 2 y Amazon Linux 2023: las correcciones se publicaron entre el 24 y el 30 de octubre.
- Fortinet: está comprobando el impacto en más de 50 productos, incluidos FortiOS, FortiGate Cloud, FortiProxy, FortiManager, FortiAnalyzer, FortiWeb, FortiSIEM y otros. El estado de la investigación es «en curso».
Recomendaciones de protección
La actualización del kernel seguida de un reinicio es la única solución completa, como subrayan tanto Red Hat como Canonical. Hasta instalar el parche, hay medidas temporales que reducen, pero no eliminan, el riesgo:
Filtrado de paquetes IPv4 TCP con opciones IP. Red Hat ha publicado la siguiente regla de nftables:
table inet cve_2026_98432 {
chain input {
type filter hook input priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 counter drop
}
}Esta regla bloquea el vector de ataque conocido, pero tiene limitaciones: solo actúa en el host donde está cargada y no filtra el tráfico entre contenedores en el mismo host. Además, la regla puede interrumpir el funcionamiento de aplicaciones que utilicen opciones IPv4.
Desactivar MPTCP no es una medida suficiente. Red Hat indica explícitamente que MPTCP no es un prerrequisito de la vulnerabilidad: los sistemas con MPTCP desactivado siguen siendo vulnerables. Canonical lo confirma: «El equipo de seguridad de Ubuntu considera que las actualizaciones de seguridad son la única medida de protección adecuada».
Para comprobar la versión actual del kernel utilice uname -r y compare el resultado con las versiones de paquetes corregidos para su distribución.
Teniendo en cuenta la existencia de código PoC público que demuestra la condición de carrera, la valoración crítica por parte de la mayoría de los proveedores y la amplitud de los sistemas afectados —desde servidores hasta plataformas de contenedores—, la actualización del kernel debe considerarse una tarea prioritaria. Se recomienda a los administradores de RHEL instalar los parches publicados de inmediato; a los administradores de Ubuntu que no puedan esperar a que los paquetes pasen de -proposed al canal principal, evaluar la posibilidad de una actualización temprana a través de -proposed, teniendo en cuenta los riesgos propios de un canal de pruebas.
