johnhsb/linux-tcp-uaf-cve-2026-98432CVE-2026-98432 (UAF en inet_opt de TCP IPv4 de Linux): script de diagnóstico de solo lectura, mitigaciones de nftables/sysctl sin reinicio, despliegue con Ansible y guía de respuesta (EN/KO)
Un kit de respuesta para CVE-2026-98432, un fallo de seguridad de memoria en el código que el kernel de Linux utiliza para establecer conexiones TCP. Contiene tres cosas:
iptables, instalado por defecto, o nftables donde falta iptables), archivos de configuración del kernel (sysctl) y playbooks de Ansible, todos aplicados sin reiniciar. El modo predeterminado solo cuenta paquetes.Escrito a fecha de 2026-11-03. Todas las mitigaciones aquí son temporales y no sustituyen la corrección del kernel. Programe la actualización del kernel y el reinicio (o un livepatch) por separado.
| README | Guía | Script de diagnóstico | |
|---|---|---|---|
| 🇺🇸 Inglés (predeterminado) | README.md | cve-2026-98432-guide.en.md | check_cve_2026_98432.sh |
| 🇰🇷 한국어 | README.ko.md | cve-2026-98432-guide.ko.md | check_cve_2026_98432_ko.sh |
iptables, instalado por defecto, y no requiere reinicio. Por seguridad, comienza solo contando; cambie a descartar una vez que haya confirmado que ningún tráfico legítimo se ve afectado.La cabecera IP de una solicitud de conexión TCP puede — en raras ocasiones — llevar campos adicionales llamados opciones IPv4. El kernel mantiene esas opciones en memoria mientras se establece la conexión. Al limpiarla, liberaba esa memoria de inmediato, aunque otro núcleo de CPU todavía pudiera estar leyéndola.
Usar memoria después de haberla liberado se denomina use-after-free (UAF). Si mientras tanto se ha colocado algo más en ese lugar, el kernel lee datos incorrectos, lo que puede provocar:
| Elemento | Detalle |
|---|---|
| Afectados | Linux 4.4 y posterior, antes de la versión corregida de cada rama. IPv6 no está afectado |
| Gravedad | CVSS 9.8 (Crítica) según el Kernel CNA, Red Hat y Ubuntu. SUSE, Amazon y Oracle la califican como 8.1, porque ganar la carrera de temporización entre CPUs es difícil |
| Causa raíz | La memoria se liberó sin esperar el periodo de liberación segura del kernel (periodo de gracia RCU). Corrección upstream: commit e3f33b0a1d89 (kfree → kfree_rcu) |
| Versiones de kernel corregidas | 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 o posterior — para los kernels de distribución, compruebe si la corrección está incluida, no el número de versión |
Explotación: a fecha de 2026-11-03 no está en CISA KEV (el catálogo de vulnerabilidades conocidas por ser explotadas), y no se han reportado ataques en el mundo real. Muchos repositorios de GitHub afirman ser "PoCs"; ninguno está verificado — no los ejecutes en redes de producción.
Kernels corregidos por distribución (versiones y fuentes en guía §2.2)
| Distribución | Estado |
|---|---|
| RHEL 8 / 9 / 10 | ✅ Kernels corregidos publicados el 2026-11-01 (RHSA-2026:93414 / 93412 / 93413). Los nodos de OpenShift (RHCOS) aún no están corregidos |
| Debian 12 / 13 | ✅ Corregido (DSA-6568-1, DLA-4841-1, DLA-4850-1) |
| Amazon Linux 2 / 2023 | ✅ Corregido. Las AMIs optimizadas para EKS/ECS, Fargate y Bottlerocket se están desplegando |
| Rocky Linux (CIQ RLC Pro / LTS) | ✅ Todas las variantes soportadas por CIQ corregidas. Para Rocky comunitario, consulta Rocky Errata |
| Ubuntu 22.04 / 24.04 / 26.04 / 26.10 | ⏳ En curso ("trabajo en curso" a fecha de 2026-11-03) |
| Ubuntu 16.04 / 18.04 / 20.04 | ⏳ El soporte estándar ha finalizado — se esperan correcciones solo para suscriptores de Ubuntu Pro (ESM) |
| SUSE, Oracle Linux, AlmaLinux, … | Correcciones reportadas — consulta el aviso propio de cada proveedor |
El script de diagnóstico en 4. Qué hacer ahora te da el veredicto exacto. Como guía aproximada:
Para que un ataque funcione, ① el servidor necesita al menos dos núcleos de CPU (dos núcleos deben tocar la misma memoria en el mismo momento), y ② el paquete del atacante debe llegar al servidor con sus opciones IPv4 intactas.
| # | Si el servidor está… | Riesgo | Qué hacer |
|---|---|---|---|
| 1 | En una VPC interna o un nodo de Kubernetes, multinúcleo, con un listener MPTCP (incluido en contenedores) | 🔴 Root remoto | Aplica la regla de firewall y el sysctl ahora, y parchea los kernels de los nodos. Algunas redes de Kubernetes (CNIs basados en eBPF) eluden el firewall del host, así que parchear es lo primero |
| 2 | En una IP pública o detrás de un balanceador de carga L4 (AWS NLB, …) con un listener MPTCP | 🔴 Root remoto | Aplica la regla de firewall y el sysctl ahora |
| 3 | Multinúcleo con solo servicios TCP ordinarios | 🟠 Caída remota | Aplica la regla de firewall (el sysctl por sí solo no ayuda) |
| 4 | CPU única (un vCPU) | 🟡 Muy improbable que tenga éxito | Inclúyelo en el ciclo de parcheo habitual |
| 5 | Accesible solo a través de un proxy L7 (AWS ALB, CloudFront, Cloudflare, …) con acceso interno controlado | 🟡 Los paquetes de ataque nunca llegan | Parchea para defenderte de atacantes internos |
⚠️ No concluyas "no hay listener MPTCP, así que estamos a salvo". Red Hat dice que comprobar si hay listeners MPTCP es "informativo más que tranquilizador". Sin MPTCP una caída sigue siendo posible, y no se puede descartar otro método de explotación que no necesite MPTCP. Además, en los kernels de la familia RHEL 8
ss -Mpuede mostrar los listeners MPTCP como TCP simple.