CVE-2026-98432: Proxmox y AWS corrigen una carrera en TCP sobre IPv4
El use-after-free del kernel Linux afecta una ruta concreta del establecimiento de TCP sobre IPv4. Proxmox y AWS publicaron paquetes corregidos, pero las versiones y acciones dependen de cada plataforma; instalar un paquete no equivale a actualizar todos los nodos.

Proxmox y AWS publicaron correcciones para CVE-2026-98432, un fallo de uso después de liberar memoria en el kernel Linux durante el establecimiento de conexiones TCP sobre IPv4. No es una vulnerabilidad genérica de cualquier paquete TCP: el aviso de Proxmox describe condiciones concretas relacionadas con SYN que llevan opciones IPv4 o con configuraciones CIPSO/NetLabel. AWS advierte que, bajo condiciones específicas y contra un listener vulnerable alcanzable por red, un atacante remoto sin autenticación podría llegar a ejecución de código. Los avisos consultados no afirman explotación observada.
-SecureCrew dice: que el paquete se llame “kernel” no convierte cada núcleo del parque en un gemelo vulnerable; aquí importan la ruta y el paquete real.-
La carrera ocurre al preparar la respuesta TCP
El fallo nace de una carrera entre CPU. Según Proxmox, un SYN retransmitido puede procesarse en otro núcleo mientras se libera el socket de una conexión nueva; el kernel todavía podría leer las opciones IP de ese socket al construir el SYN-ACK. La corrección retrasa la liberación de esas opciones hasta que termina un periodo de gracia de RCU, el mecanismo que Linux usa para coordinar lecturas concurrentes antes de retirar memoria compartida. También existe una ruta equivalente si está activado net.ipv4.tcp_migrate_req=1 o un programa BPF de migración para reuseport.
El alcance no debe ampliarse a IPv6 nativo: Proxmox especifica que esa ruta no está afectada. El aviso centra el problema en SYN con opciones IPv4 y en entornos CIPSO/NetLabel; por eso, una revisión útil mira tanto el kernel desplegado como la configuración de red que llega a los listeners. AWS describe el riesgo remoto como ejecución de código en condiciones específicas, mientras el aviso de Proxmox detalla el defecto de memoria. Ninguno de los dos documentos permite afirmar que toda instancia con una versión base antigua esté expuesta: las distribuciones aplican backports y cada proveedor publica paquetes propios.
-SecureCrew dice: “IPv4” en el advisory es una pista para revisar la superficie real, no una excusa para olvidar cómo está configurado el host.-
Las correcciones llegan por vías distintas
En Proxmox VE, el paquete corregido indicado es proxmox-kernel-7.0.14-25-pve o su variante firmada. El administrador debe comprobar qué kernel ejecuta cada nodo y aplicar el paquete dentro de su ventana de mantenimiento; la existencia del advisory no reinicia el host por telepatía. En Amazon Linux 2 y Amazon Linux 2023, AWS publicó paquetes de kernel y pide actualizarlos y reiniciar. En instancias EC2 autogestionadas con otra distribución, la responsabilidad de obtener el paquete corregido recae en el cliente y en el aviso de esa distribución.
Amazon EKS requiere distinguir el tipo de nodo. AWS publicó la AMI optimizada para EKS v20261031; los grupos gestionados, nodos autogestionados y Karpenter que la utilicen deben pasar a esa AMI o una posterior. Para EKS Auto Mode, AWS describe el reemplazo automático, sujeto a los presupuestos de interrupción del NodePool, y no pide acción inmediata al cliente. ECS sobre EC2 necesita actualizar el kernel y reiniciar o reemplazar instancias con la AMI corregida; otros servicios administrados siguen su propio calendario. No hay una casilla única que repare, al mismo tiempo, todos los hosts, contenedores y nodos.
La prioridad operativa es hacer inventario por plataforma: Proxmox, Amazon Linux, EC2 con sistema ajeno, EKS y ECS no comparten un único mecanismo de actualización. Los equipos deberían registrar versión del kernel, paquete del proveedor, configuración de red relevante y el estado del reinicio o reemplazo de nodo. Las mitigaciones de AWS para ciertos servicios pueden reducir exposición, pero no sustituyen el paquete en instancias autogestionadas. Si una aplicación depende de disponibilidad continua, el reinicio exige una ventana o una estrategia de sustitución escalonada que respete la capacidad del clúster.
-SecureCrew dice: una AMI corregida que nadie ha desplegado sigue siendo una promesa guardada en el catálogo.-
CVE-2026-98432 pide parcheado dirigido, no pánico indiscriminado. El hecho técnico es serio porque el boletín de AWS contempla ejecución remota sin autenticación en condiciones concretas; la recomendación práctica depende del sistema y de cómo se opera. Aplica el paquete que publica tu distribución o proveedor, confirma qué nodos se han reiniciado y evita inferir que un servicio administrado ha actualizado también tus hosts propios. En este caso, “está en la nube” describe dónde corre el kernel, no quién lo mantiene.
Diccionario de la Crew
use-after-free — acceso a una zona de memoria después de que el programa la haya liberado.
SYN — segmento TCP usado para iniciar una conexión.
RCU — mecanismo de sincronización del kernel Linux para esperar a que concluyan lectores concurrentes antes de retirar datos.
CIPSO/NetLabel — mecanismos para transportar etiquetas de seguridad en paquetes IP.


