CVE-2026-98432 es una vulnerabilidad de uso de memoria liberada (use-after-free, UAF) en el manejo de conexiones TCP sobre IPv4 del kernel de Linux, explotable a través de la red y sin autenticación, que el equipo de seguridad del kernel puntúa con un 9,8 sobre 10 en CVSS 3.1. Afecta a todos los kernels desde la versión 4.4 y ya está corregida en las ramas estables, pero varias distribuciones, entre ellas Ubuntu y Red Hat, todavía no han publicado paquetes corregidos para todas sus versiones. Red Hat discrepa de la gravedad y la deja en 5,9, porque explotarla exige ganar una condición de carrera.
Las claves de la vulnerabilidad CVE-2026-98432 del kernel de Linux en 30 segundos
- El fallo está en
tcp_v4_syn_recv_sock(), que pasa opciones IP a un socket nuevo sin copiarlas y permite leerlas ya liberadas. - Tiene un CVSS 3.1 de 9,8 según el kernel, un 5,9 según Red Hat y un 7,0 según Amazon.
- Está corregido en las versiones estables 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 y 7.2.10.
- No consta explotación activa ni prueba de concepto pública, y varias distribuciones aún no han publicado paquetes.
El CVE se publicó el 15 de octubre y lo dio de alta el propio equipo del kernel de Linux, que actúa como autoridad de numeración (CNA) para su código. Según su ficha, el problema nace de dos cambios antiguos, uno de ellos el que introdujo la instalación de peticiones SYN_RECV en la tabla de conexiones, y se corrige con el commit e3f33b0a1d89, incluido en Linux 7.3-rc7 y llevado después a las ramas estables.
Cómo se produce el fallo
Cuando un servidor completa el saludo de tres pasos de TCP, el kernel convierte la petición inicial (request socket) en un socket definitivo. La función tcp_v4_syn_recv_sock() entrega al socket hijo las opciones IP de la petición sin hacer una copia. Si en ese momento llega un SYN retransmitido y otro procesador está construyendo la respuesta SYN-ACK con esas mismas opciones, puede leerlas después de que se hayan liberado, y el fallo se produce en ip_options_build().
Hay un segundo escenario parecido durante la migración de peticiones entre sockets, que solo se da si el administrador ha activado net.ipv4.tcp_migrate_req, desactivado por defecto, o usa un programa BPF de tipo SK_REUSEPORT_SELECT_OR_MIGRATE. La corrección hace que esas estructuras se liberen con kfree_rcu(), es decir, tras un periodo de gracia RCU en el que ya ningún otro procesador puede estar usándolas. IPv6 no está afectado por el fallo principal, y el escenario de migración en IPv6 quedará para un parche posterior.
Crítica para unos, moderada para otros
El 9,8 del equipo del kernel parte del peor caso: ataque por red, baja complejidad, sin privilegios ni interacción del usuario, e impacto alto en confidencialidad, integridad y disponibilidad. Ubuntu lo recoge con prioridad alta y añade una puntuación CVSS 4.0 de 8,3, que sí considera que el ataque tiene requisitos previos. Red Hat lo califica de moderado, con un 5,9: entiende que un atacante remoto sin credenciales que llegue a un servicio TCP expuesto provocaría sobre todo una caída del kernel, con un riesgo solo teórico de corrupción de memoria, y que no se ha demostrado impacto en confidencialidad ni integridad. Amazon le da un 7,0.
Para priorizar, lo relevante es que cualquier servidor con un puerto TCP abierto en IPv4 es, en principio, alcanzable, que una caída provocada a distancia ya es un problema de disponibilidad serio y que, por ahora, no hay constancia de ataques. Llega además en un año con un número récord de CVE publicadas, en el que priorizar bien es más necesario que nunca.
Estado de los parches por distribución
Debian ya ha publicado actualizaciones para trixie (DSA-6568-1, con el kernel 6.12.113-1) y para bookworm (DLA-4841-1, kernel 6.1.190-1). Ubuntu tiene la corrección en preparación para 22.04, 24.04, 26.04 y 26.10 y sus kernels de nube, mientras 20.04, 18.04 y 16.04 figuran como vulnerables sin fecha; la 14.04 no está afectada. Red Hat ha aplazado la corrección para RHEL 8, 9 y 10 y no ofrece mitigación, aunque RHEL 7 queda fuera porque no tiene el código vulnerable. Amazon Linux 2023 ya ha corregido su kernel 6.18, con el resto pendiente.
La recomendación es seguir los avisos de cada distribución, actualizar el kernel en cuanto haya paquete y reiniciar. Mientras tanto, limitar los servicios TCP expuestos a internet y no activar la migración de peticiones reduce la superficie. El impacto en servidores y nube lo analiza Revista Cloud, y los comandos para comprobar y actualizar cada sistema están en administraciondesistemas.com.
Preguntas frecuentes
¿Qué versiones del kernel corrigen CVE-2026-98432?
Las ramas estables 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 y 7.2.10, además de Linux 7.3. Los kernels de distribución tienen su propia numeración, así que hay que consultar el aviso de cada una.
¿Se está explotando?
No consta. Ninguna de las fuentes oficiales consultadas menciona ataques ni pruebas de concepto públicas.
¿Afecta a IPv6?
El fallo principal no. Solo el escenario de migración de peticiones tiene un equivalente en IPv6, que se corregirá en un parche aparte.
¿Hay alguna mitigación sin parchear?
Red Hat no recomienda ninguna. Lo razonable es limitar la exposición de servicios TCP en IPv4 y mantener desactivado net.ipv4.tcp_migrate_req, que es su valor por defecto.
Fuentes:
