Vulnerabilidad crítica de ejecución remota de código en el kernel de Linux - CVE-2026-98432

Descripción

El kernel de Linux presenta un use-after-free por condición de carrera en el establecimiento de conexiones TCP sobre IPv4. Al completarse la conexión, las opciones IP de la solicitud (ireq_opt) pasan al socket hijo sin copiarse. Si otro CPU procesa un SYN retransmitido y arma el SYNACK mientras ese socket se destruye, ip_options_build() lee memoria ya liberada. Existe un caso análogo en la migración de request sockets (net.ipv4.tcp_migrate_req=1 o un programa BPF_SK_REUSEPORT_SELECT_OR_MIGRATE). IPv6 no se ve afectado por el primer problema, y su caso análogo, solo con CALIPSO, se corregirá en un parche aparte. El defecto viene desde la rama 4.4. El commit de corrección es e3f33b0a1d89 (7.3-rc7), y el CVE se publicó el 15/10/2026.

El 27/10/2026 Anthropic publicó un informe con una cadena de laboratorio que logra root remoto contra servidores Linux con un listener MPTCP, sin credenciales ni interacción. El ataque tiene dos etapas:

1. La carrera hace que el kernel devuelva bytes extra al atacante. Uno de ellos filtra una dirección del kernel y permite evadir KASLR (unos 48 minutos).
2. El mismo defecto sobrescribe un puntero de callback y ejecuta un comando como root (unos 5 minutos).

Una carrera perdida solo falla ese handshake y no tumba el sistema, por lo que el atacante puede reintentar. El código del exploit no ha sido publicado.

Conviene considerar lo siguiente:

• El registro del CVE y el parche no mencionan MPTCP. Ese vínculo proviene solo del informe de Anthropic.
• MPTCP requiere que la aplicación lo solicite al abrir el socket. Desde Go 1.24, los programas Go lo hacen por defecto en sockets de escucha, por lo que cualquier servidor Go puede ser alcanzable.
• El equipo de seguridad de Go advierte que el defecto no es específico de MPTCP y que sistemas sin listeners MPTCP podrían ser vulnerables a ataques similares. No se ha demostrado.
• Red Hat indica que un atacante remoto con acceso a un servicio TCP expuesto podría provocar la carrera, con caída del kernel como efecto más probable.
• No figura en el catálogo KEV de CISA (copia del 28/10) y ningún aviso reporta ataques activos.

Severidad según el CNA del kernel y las distribuciones

Origen	Puntaje	Observación
CNA del kernel	CVSS 3.1: 9.8 (crítica)	Complejidad baja; añadido al CVE el 24/10
Ubuntu	Prioridad alta; CVSS 3.1: 9.8; CVSS 4.0: 8.3	Hereda el vector del CNA
Red Hat	Página del CVE: 5.9 (moderada). Archivo de aviso (29/10): 8.1 (importante)	Complejidad alta; el bug tracker subió la severidad el 29/10
SUSE	8.1 (importante)	Complejidad alta
Oracle Linux	8.1 (importante)	Complejidad alta
Amazon Linux	7.0 (importante)	—

Las diferencias entre vendors y el CNA están en la complejidad de ataque: el kernel la califica baja y los vendors, alta.

Recursos afectados

Servidores Linux y appliances basados en Linux que reciben conexiones TCP/IPv4, en especial los expuestos a Internet y los que tienen listeners MPTCP (incluidos servicios escritos en Go). Impacto posible: caída del kernel (denegación de servicio), corrupción de memoria y ejecución remota de código como root.

Producto	Estado al 30/10/2026	Versión / aviso corregido
Kernel upstream (desde 4.4)	Corregido	5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3
Ubuntu 26.10, 26.04, 24.04 y 22.04 LTS	Vulnerable, corrección en curso	Sin kernel publicado. En preparación: 7.3.0-10.10, 7.0.0-43.43, 6.8.0-149.149 y 5.15.0-203.213 respectivamente
Ubuntu 20.04, 18.04 y 16.04	Vulnerable	Sin corrección. En 14.04 son vulnerables linux-lts-xenial, linux-aws y linux-azure
Ubuntu: variantes (aws, azure, gcp, oracle, raspi, realtime, lowlatency, nvidia y otras)	Vulnerable o en curso	Ver la página de Ubuntu por paquete
Debian 13 (trixie)	Corregido (16/10)	linux 6.12.113-1 (DSA-6568-1)
Debian 12 (bookworm)	Corregido (17 y 22/10)	linux 6.1.190-1 (DLA-4841-1); linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1)
RHEL 8, 9 y 10 (incl. RT), OpenShift 4 (RHCOS)	Afectado, sin corrección ni fecha	Ninguna
RHEL 7	No afectado	—
AlmaLinux y Rocky Linux	Sin corrección	Dependen de la publicación de Red Hat
SUSE Linux Micro 6.2 y openSUSE Leap 16.0	Corregido	kernel-default 6.12.0-160000.40.1 o posterior
SLES 15 SP4 a SP6 LTSS, SLES 16.0, SLE Micro 5.3 a 5.5	En pruebas	Ninguna aún
SLES 15 SP7	Afectado, corrección en curso	Ninguna aún
Oracle Linux 7, 8, 9 y 10 (UEK)	Corregido (16/10)	ELSA-2026-500397, ELSA-2026-500398, ELSA-2026-500399
Amazon Linux 2023: kernel6.18	Corregido (24/10)	6.18.56-125.164.amzn2023 (ALAS2023-2026-3251)
Amazon Linux 2023: kernel6.12	Corregido (29/10)	6.12.113-138.209.amzn2023 (ALAS2023-2026-3335)
Amazon Linux 2 y AL2023 (paquete kernel)	Pendiente	Ninguna aún

No están afectados RHEL 7 ni SUSE Linux Enterprise Server 11 SP4. Los appliances y las distribuciones no listadas deben consultarse con su proveedor.

Solución/Mitigación

La única remediación confirmada es instalar el kernel corregido y reiniciar. Para kernels propios, actualizar a la última versión estable. El equipo del kernel no recomienda aplicar parches sueltos.

Red Hat indica que ninguna mitigación disponible cumple sus criterios de facilidad de despliegue, adecuación a la mayoría de instalaciones y estabilidad. Mientras no haya parche, las siguientes medidas reducen la superficie de ataque pero no corrigen el defecto. Deben probarse antes de aplicarse porque pueden afectar servicios que usen MPTCP o migración de sockets.

sysctl -w net.mptcp.enabled=0
sysctl -w net.ipv4.tcp_migrate_req=0

Para persistirlas, agregarlas en /etc/sysctl.d/.

Para aplicaciones Go (1.24 o superior), deshabilitar MPTCP:

• En tiempo de ejecución: variable de entorno GODEBUG=multipathtcp=0.
• En compilación: línea godebug multipathtcp=0 en el go.mod del módulo principal.
• Si el código llama a SetMultipathTCP, esa llamada anula ambas opciones.

El equipo de Go considera frágil esta mitigación. Un solo listener MPTCP olvidado mantiene vulnerable al sistema.

Estado de las correcciones

• Disponible: Debian (trixie y bookworm), Oracle Linux (UEK), SUSE Linux Micro 6.2 y openSUSE Leap 16.0, y Amazon Linux 2023 (kernel6.18 y kernel6.12).
• En curso o en pruebas: Ubuntu, resto de SUSE, Amazon Linux 2 y AL2023 (kernel).
• Sin fecha: Red Hat (RHEL 8, 9 y 10, OpenShift 4) y derivados.

Cómo verificar si un equipo está corregido

Lo que importa es el kernel en ejecución, no el instalado. Si se actualizó el paquete pero no se reinició, el equipo sigue siendo vulnerable.

Ver el kernel en ejecución con uname -r. Las distribuciones aplican el parche sin cambiar la versión, por lo que conviene revisar el changelog.

Ubuntu:

pro fix CVE-2026-98432
apt changelog linux-image-$(uname -r) | grep CVE-2026-98432

Debian:

zgrep CVE-2026-98432 /usr/share/doc/linux-image-$(uname -r)/changelog.Debian.gz

Red Hat, Oracle Linux, SUSE y Amazon Linux:

rpm -q --changelog kernel | grep CVE-2026-98432

Si el CVE aparece en el changelog del kernel en ejecución, el equipo tiene la corrección. Si no aparece, debe considerarse vulnerable.

Indicadores de compromiso

A la fecha no se han publicado indicadores de compromiso específicos, no hay explotación activa conocida y el código del exploit no es público. Como orientación, no como indicadores confirmados, conviene vigilar:

• Un volumen inusual de SYN repetidos o retransmitidos desde una misma IP hacia un mismo servicio, durante periodos prolongados. El ataque de laboratorio requirió repetir la carrera durante unos 48 minutos y una carrera perdida solo genera un handshake fallido.
• SYN entrantes con opciones IP (por ejemplo Record Route o Timestamp), que es el escenario en que el CNA del kernel basa su puntaje.
• Reinicios o caídas inesperadas del kernel en servidores con servicios expuestos.

Recomendaciones

• Inventariar los servidores Linux y los appliances basados en Linux, priorizando los expuestos a Internet.

• Identificar listeners MPTCP y servicios Go:

  ss -Mlnp
  ip mptcp endpoint show
  ip mptcp limits show
  sysctl net.ipv4.tcp_migrate_req
  

• Aplicar el kernel corregido en cuanto cada distribución lo publique, sin excluir servidores internos, y reiniciar para cargarlo.

• En Ubuntu y Red Hat, monitorear sus avisos a diario hasta que publiquen kernel corregido, y evaluar las mitigaciones temporales descritas.

• Considerar que los contenedores comparten el kernel del host. Actualizar la imagen de una aplicación no corrige esta falla.

• Restringir el acceso de redes no confiables a servicios TCP que no deban estar expuestos.

• Reportar cualquier actividad sospechosa al CGII-AGETIC.