Carrera del Handshake TCP del Kernel de Linux (CVE-2026-98432)

En resumen

• Una condición de carrera en el handshake TCP IPv4 del kernel de Linux libera las opciones IP de un socket mientras otra CPU todavía las lee. El equipo CVE del kernel la puntúa CVSS v3.1 9.8; el investigador Xinyang Ge de Anthropic la reportó y Eric Dumazet la corrigió el 2026-10-01.
• Todo kernel de Linux posterior a 4.4 está afectado, para cualquier servicio TCP IPv4 alcanzable por el atacante. Los servicios Go compilados con Go 1.24 o superior escuchan con Multipath TCP por defecto, la configuración que explotó el ataque de Anthropic.
• Anthropic dice que su modelo de IA escribió un exploit que ejecutó comandos como root, sin credenciales, en servidores Linux con un listener MPTCP. No se reportan ataques y la falla no está en el catálogo KEV de CISA al 2026-10-30.
• Instale un kernel corregido: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 o 7.3, o el paquete corregido de su distribución. Debian, Oracle, Amazon y SUSE publican en parte; Ubuntu y RHEL nada al 2026-10-30. Vea "¿Cómo lo corrijo?" para la mitigación solo para Go.

¿Estoy afectado?

Está expuesto cuando se cumplen todas estas condiciones:

• Su host ejecuta un kernel de Linux a partir de Linux 4.4 (enero de 2016) y anterior a las versiones estables corregidas. Los contenedores no traen su propio kernel: un servicio dentro de un contenedor usa el kernel del host, así que la versión del host decide.
• Un servicio TCP IPv4 de ese host es alcanzable por el atacante. Red Hat afirma que un atacante remoto que pueda alcanzar un servicio TCP expuesto puede desencadenar la carrera.
• La carrera necesita un SYN retransmitido y opciones IP en la solicitud de conexión. La puntuación del equipo del kernel describe un atacante que envía una solicitud con opciones IPv4 Record Route o Timestamp y luego la reenvía: ambos lados de la carrera son inducidos por el atacante.

Dos rutas de configuración amplían la exposición. Un servidor con un listener Multipath TCP es la configuración que explotó Anthropic, y todo programa Go compilado con Go 1.24 o superior abre sus sockets de escucha con MPTCP por defecto en Linux. Además, la migración de sockets de solicitud, activada con net.ipv4.tcp_migrate_req=1 o un programa BPF de migración reuseport, expone el mismo use-after-free por una segunda ruta.

La tabla tiene 11 filas; 8 llevan una corrección publicada y las 3 restantes no. Amazon Linux 2 y el paquete de kernel por defecto de Amazon Linux 2023 tampoco tienen corrección, y Ubuntu lista sus kernels cloud, FIPS y de tiempo real como vulnerables o en progreso.

Compruebe lo que ejecuta cada host:

# Host kernel version
uname -r
# Compare against the fixed versions above; on Ubuntu and RHEL, watch the
# vendor advisory instead, because package versions differ from upstream tags.

# Debian: installed kernel packages and status
dpkg -l 'linux-image*' | grep '^ii'

# RHEL, Oracle Linux, Amazon Linux: installed kernels
rpm -q kernel kernel-uek kernel6.12 kernel6.18 2>/dev/null

# Which Go toolchain built a service (Go 1.24+ enables MPTCP by default)
go version -m /path/to/service | head -1

¿Cómo lo corrijo?

1. En Ubuntu o RHEL, no existe aún ningún kernel corregido para instalar al 2026-10-30. Red Hat afirma que ninguna mitigación disponible cumple sus criterios de despliegue fácil, aptitud para la mayoría de instalaciones y estabilidad. Vigile la página CVE de Ubuntu y la de Red Hat, y tome la opción de Go de abajo solo como medida provisional.
2. Instale el paquete corregido de su distribución y reinicie. En Debian: apt update && apt install linux-image-amd64, luego reinicie. En Oracle Linux: dnf update kernel-uek, luego reinicie. En Amazon Linux 2023: dnf update kernel6.18 o kernel6.12, luego reinicie.
3. En SUSE Linux Micro 6.2 u openSUSE Leap 16.0: zypper in kernel-default>=6.12.0-160000.40.1, luego reinicie.
4. Si compila su propio kernel, pase a una de las versiones estables corregidas. El equipo CVE del kernel recomienda actualizar a la última versión estable y afirma que la comunidad no da soporte a la selección manual de correcciones individuales.

El equipo de seguridad de Go ofrece una mitigación real para los servicios en Go 1.24 o posterior, con sus propias advertencias. Configure GODEBUG=multipathtcp=0 en el entorno del programa para desactivar MPTCP en tiempo de ejecución, o ponga godebug multipathtcp=0 en el go.mod del módulo principal para desactivarlo en tiempo de compilación. Los programas también pueden llamar a net.ListenConfig.SetMultipathTCP(false) por socket. El equipo califica la desactivación de MPTCP programa por programa de mitigación frágil: un solo listener MPTCP restante deja el sistema expuesto, y asume que todo exploit viable depende de MPTCP. El equipo recomienda encarecidamente actualizar a un kernel corregido.

Tenga en cuenta el alcance: ninguna mitigación del fabricante cubre la carrera subyacente para listeners que no son MPTCP, y Red Hat dice que el resultado más probable allí es un cuelgue del kernel, con corrupción de memoria posible en teoría.

¿Cuál es la causa raíz?

El kernel libera las opciones IP adjuntas a una solicitud de conexión TCP mientras otra CPU todavía las lee, porque la liberación usa kfree() en lugar de esperar a los lectores de RCU.

La capa IP guarda las opciones de una solicitud de conexión IPv4 entrante, como Record Route o Timestamp, junto al socket de solicitud. Cuando el handshake se completa, tcp_v4_syn_recv_sock() en net/ipv4/tcp_ipv4.c entrega ese puntero de opciones al nuevo socket hijo en lugar de copiarlo. Desde el commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table"), los sockets de solicitud se procesan sin mantener el candado del listener.

El mensaje del commit de corrección describe las dos CPU en colisión. Otra CPU puede procesar a la vez un SYN retransmitido para la misma solicitud y enviar un SYNACK desde tcp_check_req(). tcp_v4_send_synack() e inet_csk_route_req() leen ireq->ireq_opt solo bajo rcu_read_lock(), y luego ip_build_and_send_pkt() e ip_options_build() leen opt->optlen dos veces. Nada impide que el socket hijo se libere mientras ese SYNACK todavía se construye.

// net/ipv4/af_inet.c, inet_sock_destruct(), before the fix
void inet_sock_destruct(struct sock *sk)
{
    ...
    WARN_ON_ONCE(sk->sk_wmem_queued);
    WARN_ON_ONCE(sk->sk_forward_alloc);

-   kfree(rcu_dereference_protected(inet->inet_opt, 1));
+   kfree_rcu(rcu_dereference_protected(inet->inet_opt, 1), rcu);

inet_sock_destruct() libera las opciones del socket hijo con un simple kfree(). Los sockets hijos TCP no tienen SOCK_RCU_FREE, así que la liberación es inmediata. Una segunda CPU todavía dentro de rcu_read_lock() lee entonces las opciones liberadas en ip_options_build(): un use-after-free.

// net/ipv4/tcp_ipv4.c, tcp_v4_reqsk_destructor(), before the fix
static void tcp_v4_reqsk_destructor(struct request_sock *req)
{
-   kfree(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1));
+   kfree_rcu(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1), rcu);
}

La segunda ruta es la migración de sockets de solicitud, activada por net.ipv4.tcp_migrate_req=1 o un programa BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. reqsk_timer_handler() clona el socket de solicitud con inet_reqsk_clone(), de modo que el socket antiguo y su clon comparten el mismo ireq_opt. Cuando el clon se libera, tcp_v4_reqsk_destructor() libera las opciones con kfree() mientras otra CPU con una referencia sobre el socket antiguo puede seguir usándolas.

IPv6 no está afectado por la primera ruta, porque tcp_v6_syn_recv_sock() duplica las opciones. El commit señala que tcp_v6_reqsk_destructor() tiene el mismo problema de migración para opciones CALIPSO y dice que se abordará en un parche separado.

¿Cómo se explota?

No hay código de exploit público. Anthropic describe el ataque que escribió su modelo de IA interno, en cuatro pasos:

1. El atacante envía una solicitud de conexión TCP IPv4 con opciones IP a un servicio alcanzable, y luego reenvía la solicitud para ganar la carrera, como describe la puntuación del equipo del kernel.
2. La carrera hace que el kernel lea una longitud controlada por el atacante y copie bytes extra de vuelta al atacante. En cuanto una de esas sobrelecturas devuelve un puntero del kernel, el atacante ha derrotado a KASLR, la aleatorización de direcciones del kernel.
3. El mismo use-after-free desborda entonces un búfer y sobrescribe un puntero de callback con la dirección de una carga que el atacante preparó en memoria del kernel mediante una función ordinaria del protocolo.
4. El kernel invoca el callback. La carga encadena llamadas a funciones existentes del kernel y termina con un comando shell elegido por el atacante, ejecutado como root.

Una carrera perdida solo hace fracasar ese intento de conexión y no cuelga el sistema, así que un atacante decidido puede reintentar indefinidamente. En la prueba de concepto de Anthropic, filtrar un puntero del kernel tomó 48 minutos y alcanzar la ejecución del comando shell 5 minutos más.

¿Cómo fluye el ataque?

En una frase: el atacante gana la carrera del handshake TCP IPv4 de modo que el kernel libera las opciones IP de la solicitud mientras otra CPU todavía las lee en la ruta del SYNACK, y luego convierte el use-after-free en una fuga de KASLR y un callback secuestrado que ejecuta un comando root.

¿Qué puede hacer un atacante?

La puntuación 9.8 del equipo del kernel asume acceso por red, sin privilegios y sin interacción del usuario, con alto impacto en confidencialidad, integridad y disponibilidad (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). En ese escenario, la falla podría devolver al atacante memoria cercana del kernel, corromper memoria del kernel o colgar el sistema.

Anthropic demostró el resultado más fuerte: comandos arbitrarios como root, sin credenciales y sin interacción del usuario, en servidores que exponen un listener MPTCP. Su publicación no nombra la versión del kernel ni la configuración probadas, y no dice si los servidores sin listener MPTCP pueden tomarse de la misma forma.

Red Hat califica la falla como Important, 8.1, con el vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, tanto en su página CVE como en su archivo de aviso legible por máquina, actualizado el 2026-10-29. Según Red Hat, la falla provoca sobre todo un cuelgue del sistema (denegación de servicio) o una posible corrupción de memoria, y la puntuación es preliminar. Oracle, SUSE y Amazon también la puntúan 8.1 con el mismo vector. Cada puntuación difiere de la del equipo del kernel solo en la complejidad del ataque, alta para los fabricantes y baja para el equipo del kernel.

¿Por qué funciona la corrección?

La corrección, commit e3f33b0a1d89d738e2b913dab519226eaf76e15b, sustituye kfree() por kfree_rcu() en los dos destructores, inet_sock_destruct() y tcp_v4_reqsk_destructor(). kfree_rcu() retrasa la reclamación hasta que pasa un periodo de gracia de RCU, así que toda CPU que mantenga rcu_read_lock() sobre las opciones termina de leerlas antes de que se libere la memoria. Los lectores ya usaban RCU, y las otras rutas que reemplazan inet_opt, como do_ip_setsockopt(), ya usaban kfree_rcu().

El cambio de dos líneas es completo para las dos rutas IPv4 nombradas en el commit: la carrera del SYNACK vía inet_sock_destruct() y la carrera de migración vía tcp_v4_reqsk_destructor(). El propio commit señala un punto adyacente que no toca: el problema equivalente en IPv6 para opciones CALIPSO, que dice que un parche separado abordará.

¿Cómo compruebo si estuve comprometido?

No se ha reportado ninguna explotación en ningún lugar al 2026-10-30, y no se han publicado indicadores ni reglas de detección. Un intento que pierde la carrera solo hace fracasar ese intento de conexión, de modo que el sondeo puede dejar poca huella.

El mecanismo sugiere el aspecto de un sondeo intenso: muchos intentos de conexión IPv4 efímeros con opciones Record Route o Timestamp, seguidos de solicitudes retransmitidas al mismo puerto de escucha. Trate ese patrón como una pista a investigar, no como prueba de compromiso; ninguna fuente publicada documenta tráfico observado de esta forma.

Cronología

• 2016-01-10: Se publica Linux 4.4. The Hacker News reporta que la falla se introdujo en esta versión, con el cambio de sockets de solicitud que luego quitó el candado del listener de la ruta en carrera.
• 2026-10-01: Eric Dumazet escribe la corrección, "ipv4: free inet_opt and ireq_opt after an RCU grace period", reportada por Xinyang Ge de Anthropic.
• 2026-10-05: Los desarrolladores del kernel aplican la corrección en upstream, diez días antes de publicarse el CVE.
• 2026-10-11 a 2026-10-15: La corrección se retroporta a las ramas estables 5.10, 5.15, 6.1, 6.6, 6.12, 6.18 y 7.2.
• 2026-10-15: El equipo CVE del kernel publica CVE-2026-98432.
• 2026-10-16: Debian trixie y Oracle Linux publican kernels corregidos (DSA-6568-1; ELSA-2026-500397 a 500399).
• 2026-10-17 a 2026-10-22: Debian 12 bookworm recibe kernels corregidos en dos avisos (DLA-4841-1, DLA-4850-1).
• 2026-10-24: El equipo CVE del kernel añade la puntuación 9.8 al registro, nueve días después de publicar el CVE. Amazon corrige su paquete kernel6.18 (ALAS2023-2026-3251).
• 2026-10-27: Anthropic publica su artículo describiendo el exploit escrito por IA que alcanzó root en servidores con listener MPTCP.
• 2026-10-29: Amazon corrige su paquete kernel6.12 (ALAS2023-2026-3335). La página CVE y el archivo de aviso de Red Hat pasan a Important, 8.1. SUSE publica kernels corregidos para SLES 15 SP4 a SP6 LTSS y SLE Micro 5.3 a 5.5. The Hacker News publica la tabla de estado de las distribuciones.
• 2026-10-30: Ubuntu y RHEL siguen sin listar ningún kernel corregido. Ninguna de las dos da fecha.

Preguntas frecuentes

¿Mi servicio Go necesita la corrección del kernel aunque nunca llame a las API de MPTCP?

Sí. Go 1.24 y posteriores activan MPTCP por defecto para los sockets de escucha en Linux, así que un simple net.Listen ya lo usa sin ninguna llamada MPTCP en su código. Compruebe la compilación con go version -m, y vea "¿Cómo lo corrijo?" para la mitigación temporal con GODEBUG.

¿Están afectados los contenedores?

La falla está en el kernel del host, así que un contenedor no se libera de la exposición por el empaquetado. Cualquier servicio TCP IPv4 alcanzable por el atacante en un host afectado, dentro o fuera de un contenedor, da al atacante la posición de red que la carrera necesita. La corrección es el paquete del kernel del host.

¿Pueden los atacantes apuntar también a listeners IPv6?

No por la primera ruta. El kernel copia las opciones para las conexiones IPv6, así que la carrera del handshake es solo IPv4. El commit de la corrección señala un problema de migración IPv6 para opciones CALIPSO que un parche separado abordará.

¿Por qué el equipo del kernel dice 9.8 y Red Hat y otros fabricantes dicen 8.1?

El equipo del kernel puntúa la complejidad del ataque como baja porque el atacante induce ambos lados de la carrera: la solicitud inicial con opciones IP y la retransmisión. Red Hat, Oracle, SUSE y Amazon la puntúan como alta, lo que baja la puntuación a 8.1 con el mismo impacto alto en confidencialidad, integridad y disponibilidad.

¿Se explota la falla en la naturaleza?

Ninguna fuente reporta ataques al 2026-10-30. La falla no está en el catálogo KEV de CISA, comprobado en el feed JSON del catálogo en esa fecha. El exploit de Anthropic y su prueba siguen siendo la única ejecución demostrada.

No puedo reiniciar este mes. ¿Cuál es mi mejor movimiento?

Instale el kernel corregido en cuanto su distribución lo publique y, hasta entonces, aplique la mitigación temporal de MPTCP del equipo de Go a los servicios en Go 1.24 o posterior, conociendo sus límites. Red Hat no publica ninguna mitigación aceptada: mantenga los servicios IPv4 expuestos detrás de listas de acceso estrictas y vigile los avisos de Ubuntu y Red Hat a diario.

Encuentre primero los hosts Linux que debe corregir con Ostorlab

El descubrimiento de superficie de ataque de Ostorlab inventaría sus hosts expuestos a Internet y los servicios que abren, para que pueda listar los servidores Linux con listeners TCP IPv4 alcanzables y comprobar sus kernels primero.

Referencias

• Registro CVE-2026-98432, CNA kernel.org, publicado el 2026-10-15, actualizado el 2026-10-30, CVSS v3.1 9.8 y los commits de retroporte estable: https://cveawg.mitre.org/api/cve/CVE-2026-98432 (consultado el 30 de octubre de 2026)
• Commit de corrección e3f33b0a1d89d738e2b913dab519226eaf76e15b, "ipv4: free inet_opt and ireq_opt after an RCU grace period", Eric Dumazet, 2026-10-01: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e3f33b0a1d89d738e2b913dab519226eaf76e15b (consultado el 30 de octubre de 2026)
• Anthropic, "Discovering and exploiting vulnerabilities in critical, real-world software with Claude", 27 de octubre de 2026, capítulo 5: https://www.anthropic.com/research/discovering-vulnerabilities-with-claude (consultado el 30 de octubre de 2026)
• The Hacker News, "Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions", 29 de octubre de 2026, la tabla de estado de distribuciones y el razonamiento de la puntuación: https://thehackernews.com/2026/10/linux-kernel-tcp-flaw-with-98-cvss.html (consultado el 30 de octubre de 2026)
• Equipo de seguridad de Go, "[security] Protecting against CVE-2026-98432", golang-announce, 29 de octubre de 2026: https://groups.google.com/d/msgid/golang-announce/0c2926bc-e90f-4cdb-97c3-300fff6d8885n%40googlegroups.com (consultado el 30 de octubre de 2026)
• La misma guía de Go reenviada a oss-security, 29 de octubre de 2026: https://www.openwall.com/lists/oss-security/2026/10/30/1 (consultado el 30 de octubre de 2026)
• Página CVE-2026-98432 de Ubuntu, ningún paquete de kernel marcado como corregido al 30 de octubre de 2026: https://ubuntu.com/security/CVE-2026-98432 (consultado el 30 de octubre de 2026)
• Aviso legible por máquina de Red Hat para CVE-2026-98432, Important 8.1, actualizado el 2026-10-29: https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-98432.json (consultado el 30 de octubre de 2026)
• Página CVE de Red Hat para CVE-2026-98432: https://access.redhat.com/security/cve/cve-2026-98432 (consultado el 30 de octubre de 2026)
• Debian DSA-6568-1, linux 6.12.113-1, 16 de octubre de 2026: https://lists.debian.org/debian-security-announce/2026/msg00482.html (consultado el 30 de octubre de 2026)
• Página de erratas de Oracle Linux para CVE-2026-98432, ELSA-2026-500397 a 500399, publicadas el 2026-10-16: https://linux.oracle.com/cve/CVE-2026-98432.html (consultado el 30 de octubre de 2026)
• Aviso de Amazon Linux 2023 ALAS-2026-3251, kernel6.18-6.18.56-125.164, publicado el 2026-10-24: https://alas.aws.amazon.com/AL2023/ALAS2023-2026-3251.html (consultado el 30 de octubre de 2026)
• Aviso de Amazon Linux 2023 ALAS-2026-3335, kernel6.12-6.12.113-138.209, publicado el 2026-10-29: https://alas.aws.amazon.com/AL2023/ALAS2023-2026-3335.html (consultado el 30 de octubre de 2026)
• Página de SUSE para CVE-2026-98432, Important 8.1, estado de corrección por paquete: https://www.suse.com/security/cve/CVE-2026-98432.html (consultado el 30 de octubre de 2026)
• Ficha NVD de CVE-2026-98432, mostrando la puntuación 9.8 del equipo del kernel: https://nvd.nist.gov/vuln/detail/CVE-2026-98432 (consultado el 30 de octubre de 2026)
• Registro publicado por el equipo CVE del kernel para CVE-2026-98432, recomendando el último kernel estable: https://kernel.googlesource.com/pub/scm/linux/security/vulns/+/refs/heads/master/cve/published/2026/CVE-2026-98432.mbox (consultado el 30 de octubre de 2026)
• Documentación del kernel sobre Multipath TCP: https://docs.kernel.org/networking/mptcp.html (consultado el 30 de octubre de 2026)
• Incidencia de Go que sigue la discusión, go.dev/issue/82717: https://go.dev/issue/82717 (consultado el 30 de octubre de 2026)
• Feed JSON del catálogo KEV de CISA, comprobado para CVE-2026-98432 el 30 de octubre de 2026 (no listado): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (consultado el 30 de octubre de 2026)