CVE-2026-98432, un fallo de uso de memoria liberada en el código TCP sobre IPv4 del kernel de Linux con un CVSS 3.1 de 9,8 según el equipo del kernel, afecta a todos los servidores con kernel 4.4 o posterior y se corrige actualizando el kernel y reiniciando. Las ramas estables ya incluyen la corrección y Debian ha publicado paquetes, pero Ubuntu y Red Hat todavía los tienen en preparación para buena parte de sus versiones. Estos son los pasos para saber si un sistema está expuesto y cómo actualizarlo.
Las claves para parchear CVE-2026-98432 en 30 segundos
- Afecta al kernel desde la 4.4; las versiones estables corregidas son 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 y 7.2.10.
- Debian ya tiene paquetes para trixie y bookworm; Ubuntu y Red Hat, aún no para todas sus versiones.
- Basta con instalar el nuevo kernel en cuanto lo publique la distribución y reiniciar, porque hasta entonces sigue en uso el antiguo.
- Mientras tanto, conviene limitar los servicios TCP expuestos a internet y mantener desactivado tcp_migrate_req.
El fallo está en tcp_v4_syn_recv_sock(): al crear el socket definitivo de una conexión, el kernel le pasa las opciones IP de la petición inicial sin copiarlas, y un SYN retransmitido procesado en paralelo puede leerlas ya liberadas. Un atacante remoto sin credenciales podría provocar así, como mínimo, la caída del kernel. El equipo del kernel le da un 9,8, mientras que Red Hat lo rebaja a 5,9 y Amazon a 7,0 por la dificultad de ganar la condición de carrera. No consta explotación activa. El análisis completo del impacto en servidores y nube está en Revista Cloud, y el de seguridad, en OpenSecurity.
Cómo saber si un servidor está afectado
El primer paso es ver qué kernel está en ejecución, que no siempre coincide con el instalado si el equipo no se ha reiniciado:
uname -rSi el sistema usa un kernel de una rama estable compilado a partir de kernel.org, basta con compararlo con las versiones corregidas. En las distribuciones, en cambio, el número del paquete no coincide con el de kernel.org, porque cada una aplica sus propios parches, así que hay que fiarse de sus avisos. En Debian, la corrección llega con el kernel 6.12.113-1 en trixie (DSA-6568-1) y 6.1.190-1 en bookworm (DLA-4841-1). Ubuntu la tiene en preparación para 22.04 (5.15.0-203), 24.04 (6.8.0-149), 26.04 (7.0.0-43) y 26.10 (7.3.0-10), pero a 28 de octubre no había publicado los paquetes; 20.04, 18.04 y 16.04 aparecen como vulnerables sin fecha. Red Hat ha aplazado la corrección para RHEL 8, 9 y 10, y RHEL 7 no está afectado.
También conviene comprobar si está activada la migración de peticiones TCP, que abre el segundo escenario del fallo. Por defecto vale 0:
sysctl net.ipv4.tcp_migrate_reqLenguaje del código: CSS (css)Cómo actualizar en Debian, Ubuntu y RHEL
En Debian y Ubuntu, el kernel se actualiza con el resto de paquetes. El primer comando refresca los repositorios, el segundo muestra si hay un kernel nuevo disponible y el tercero lo instala:
sudo apt update
apt list --upgradable 2>/dev/null | grep linux-image
sudo apt full-upgradeLenguaje del código: JavaScript (javascript)En Ubuntu, el fichero /var/run/reboot-required indica si hace falta reiniciar. En RHEL, Rocky, AlmaLinux y derivados, cuando el paquete esté publicado, la actualización es:
sudo dnf update kernel
rpm -q kernelEn todos los casos, el parche no protege hasta que el sistema arranca con el kernel nuevo, así que hay que reiniciar y volver a comprobar uname -r. En máquinas virtuales en la nube, esta tarea es del cliente, también en los kernels específicos de cada proveedor, como linux-aws, linux-azure o linux-gcp en Ubuntu.
Qué hacer mientras no hay parche
Red Hat no recomienda ninguna mitigación concreta. Lo razonable es reducir la superficie: cerrar en el cortafuegos los puertos TCP que no necesiten estar abiertos a internet, poner detrás de una VPN o de una lista de IP permitidas los servicios de administración y no activar net.ipv4.tcp_migrate_req ni programas BPF de migración de peticiones. Como el fallo principal no afecta a IPv6, los servicios que solo escuchan en IPv6 quedan fuera de ese escenario. Y conviene suscribirse a las listas de avisos de seguridad de la distribución para aplicar el parche en cuanto se publique.
Preguntas frecuentes
¿Cómo sé si mi kernel está parcheado contra CVE-2026-98432?
Comprueba el kernel en ejecución con uname -r y compáralo con el aviso de seguridad de tu distribución. Con kernels de kernel.org, las versiones corregidas son 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 y 7.2.10 o posteriores.
¿Hace falta reiniciar?
Sí. El kernel nuevo solo se usa tras reiniciar el sistema.
¿Está afectado RHEL 7?
No. Según Red Hat, RHEL 7 no contiene el código vulnerable. Sí lo están RHEL 8, 9 y 10.
Fuentes:
