Qué describe la ficha, función por función
La ficha de Ubuntu describe un fallo de gestión de memoria en el establecimiento de conexiones TCP sobre IPv4. Cuando un cliente envía un SYN, el kernel crea una solicitud de conexión; al final del handshake, tcp_v4_syn_recv_sock() crea el socket hijo. Según la ficha, esta función entrega al socket hijo las opciones IP de la solicitud sin copiarlas. Si un SYN retransmitido se procesa a la vez en otro procesador, el kernel puede leer esas opciones ya liberadas al construir el SYNACK: es el uso tras liberación, en ip_options_build().
La ficha señala una carrera análoga durante la migración de solicitudes entre sockets, cuando net.ipv4.tcp_migrate_req=1 o un programa BPF_SK_REUSEPORT_SELECT_OR_MIGRATE está activo. El parche descrito retrasa la liberación de la memoria hasta el final de un periodo de gracia RCU, con kfree_rcu(), en inet_sock_destruct() y tcp_v4_reqsk_destructor(). IPv6 no se ve afectado por el primer fallo; la ficha indica que existe un fallo de migración parecido en ese lado y que se tratará por separado. Tenga presente también lo que no dice: la explotabilidad remota no está demostrada públicamente en las fichas leídas.
Dos puntuaciones, dos emisores: 9,8 y 8,1
Las dos cifras no se contradicen: describen cosas distintas. Ubuntu muestra una prioridad High y una puntuación CVSS 3 de 9,8, calificada como Critical. Red Hat publica un CVSS v3.1 de 8,1, con el vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. La página de Red Hat da también, a modo de comparación, el valor de cve.org: 9,8 con AC:L. Solo cambia la complejidad del ataque: baja (AC:L) en un lado, alta (AC:H) en el otro.
El 8,1 de Red Hat refleja una carrera de temporización muy ajustada, en la que el atacante debe hacer coincidir dos tratamientos en dos procesadores; su descripción habla ante todo de una caída, con una posible corrupción de memoria. La página precisa que estas puntuaciones son preliminares y están sujetas a revisión. No se quede, pues, con una cifra única: 9,8 según Ubuntu, 8,1 según Red Hat. En los vectores publicados por Red Hat y cve.org, el fallo es alcanzable por red sin autenticación (AV:N, PR:N), lo que basta para tomarlo en serio sin presentarlo como un ataque en curso: ninguna de las dos fichas leídas señala uno.
El estado publicado el 30 de octubre de 2026
Desplace la tabla
| Fuente o versión | Estado leído en la ficha | Qué cambia para usted |
|---|---|---|
| Ubuntu 24.04 LTS (noble) | Vulnerable, parche en curso; versión listada 6.8.0-149.149 | Aún no hay kernel corregido que instalar |
| Ubuntu 22.04 LTS (jammy) | Vulnerable, parche en curso; versión listada 5.15.0-203.213 | Aún no hay kernel corregido que instalar |
| Ubuntu 26.04 LTS | Vulnerable, parche en curso; versión listada 7.0.0-43.43 | Aún no hay kernel corregido que instalar |
| Ubuntu 20.04 LTS (focal) | Ninguna versión listada; revise el estado en la ficha | Volver a abrir la ficha antes de concluir |
| Red Hat | CVSS v3.1 8,1, ninguna mitigación propuesta, ningún paquete corregido listado, Bugzilla 2553390 | No hay solución alternativa oficial; seguir el ticket |
| Debian, AlmaLinux, Rocky y otras | No leído para este artículo | Leer el aviso de su proveedor, sin deducirlo de Ubuntu |
| Un número de versión en una ficha | No es una versión corregida mientras el estado no haya pasado a corregido | Compare `uname -r` con ese número solo tras ese cambio de estado |
Un kernel instalado no es un kernel en ejecución
Un apt upgrade o un dnf update deja un kernel nuevo en /boot, pero el sistema sigue ejecutando el cargado en el último arranque hasta que se reinicia. uname -r responde a la única pregunta que importa aquí: qué kernel se está ejecutando ahora. La lista de paquetes responde a otra: qué kernels duermen en el disco. Cuando salga el parche, un VPS puede mostrar «al día» en su gestor de paquetes y seguir siendo vulnerable durante semanas.
Hoy ocurre lo contrario: instalar las actualizaciones del día no corrige esta CVE, porque las fichas no listan ningún kernel corregido. Los contenedores Docker no cambian nada, comparten el kernel de la máquina. En una máquina virtual completa ese kernel es suyo; en un VPS de tipo contenedor es el del anfitrión, y hay que pedirlo al proveedor. El procedimiento de reinicio se detalla en la guía de PwnEscape y Vghost enlazada bajo este artículo: no hace falta repetirlo aquí.
Verificar su VPS en diez minutos
Leer el kernel en ejecución
uname -rcat /proc/version
Anote la cadena completa, sufijo incluido (-generic,-aws,-kvm,el9…). Es la que comparará con la ficha de su distribución, y el sufijo indica la variante de kernel que debe buscar.Listar los kernels instalados y el reinicio pendiente
Debian, Ubuntu:
dpkg -l 'linux-image*' | grep '^ii'y luegols /var/run/reboot-required
RHEL, AlmaLinux, Rocky:rpm -q kernely luegosudo needs-restarting -r
Si el kernel instalado más reciente difiere del que indicauname -r, hay un reinicio pendiente.Buscar un parche publicado
Debian, Ubuntu:
sudo apt updatey luegoapt list --upgradable 'linux-image*'
RHEL, AlmaLinux, Rocky:sudo dnf updateinfo list --cve CVE-2026-98432y luegosudo dnf check-update kernel
Una lista vacía no prueba que esté protegido: solo dice que su repositorio no ofrece nada por ahora.Leer lo que anuncia el paquete candidato
Debian, Ubuntu:
apt changelog <paquete-listado-en-el-paso-anterior> | grep -n 'CVE-2026-98432'
RHEL, AlmaLinux, Rocky:sudo dnf updateinfo info --cve CVE-2026-98432
Si el identificador aparece, el paquete anuncia el parche; anote su número de versión y confírmelo en la ficha de su distribución antes de concluir.Leer la exposición de red
sudo ss -4tlnpsysctl net.ipv4.tcp_migrate_req
La primera orden lista los puertos TCP IPv4 en escucha, es decir, los únicos sitios donde llega un handshake TCP; es nuestra lectura de la ficha, no una afirmación de ella. La segunda muestra el estado del ajuste de migración (0o1). Ese ajuste no cierra el fallo: el primer fallo descrito existe sin él.Volver a abrir la ficha el día de la decisión
Abra la ficha de su distribución, anote el estado de su variante de kernel y la fecha de última actualización que muestra. Regístrelos con la fecha de lectura: estas páginas cambian, y un estado leído hace tres días no es el de hoy.
Actuar sin parche confirmado
- Cerrar lo que no tiene por qué ser accesible — cada puerto TCP IPv4 abierto a todo Internet es una posible entrada. Restrinja SSH, bases de datos y administración a las direcciones necesarias con
ufwofirewalld. Reduce la superficie, pero no corrige un puerto público como el 443. - No confiar en una solución alternativa — Red Hat no propone ninguna, y la parte leída de la ficha de Ubuntu tampoco lista ninguna. Poner
net.ipv4.tcp_migrate_reqa0no cubre el primer fallo descrito. - Preparar la ventana de reinicio — elija la franja, avise a los usuarios, compruebe que sus servicios arrancan solos (
systemctl is-enabled <servicio>) y haga antes una copia de seguridad o una instantánea. - Detectar el parche en cuanto se publique — ejecute cada día
apt list --upgradable 'linux-image*'odnf check-update kernel, o relea la ficha. Según su configuración, la actualización automática instala el kernel sin reiniciar. - Tener un acceso de emergencia — localice la consola de emergencia de su proveedor antes del reinicio, no durante: un kernel que no arranca se resuelve desde ahí.
- Vigilar las caídas — Red Hat describe sobre todo una caída.
journalctl -k -p err --since '7 days ago'ylast -x rebootmuestran un reinicio inesperado o un mensaje del kernel inusual que conviene comparar con la fecha de publicación.
Livepatch: una opción, con una condición
Un parche en caliente aplica una corrección al kernel en ejecución, sin reiniciar. Solo existe cuando lo ha producido el editor o el proveedor del servicio, y cubre únicamente las CVE que este ha tratado. Con el servicio Livepatch de Canonical, canonical-livepatch status --verbose indica las correcciones aplicadas; en otras distribuciones, servicios de terceros como KernelCare cumplen ese papel. La regla es la misma en todas partes: mientras el identificador CVE-2026-98432 no aparezca en la lista de correcciones aplicadas, no está cubierto, aunque el servicio figure como activo.
Ninguna de las fichas leídas menciona un livepatch para esta CVE en la fecha de consulta. Y un livepatch no exime del kernel siguiente: prevea de todos modos el reinicio hacia la versión corregida, en la franja que haya elegido.
Anote la fecha, no solo el estado
En su cuaderno de operaciones, anote para cada servidor el kernel en ejecución, el estado leído en la ficha y la fecha de lectura. En esta guía, el estado descrito es el del 30 de octubre de 2026; puede haber cambiado cuando la lea. Esta guía se ofrece tal cual: la administración de su servidor sigue siendo responsabilidad suya, sin soporte por nuestra parte.
El día en que aparezca un kernel corregido
Lea primero la ficha: el estado de su variante debe haber pasado a corregido e indicar un número de versión. La ficha de Ubuntu no lista un solo paquete sino varios (linux, linux-aws, linux-azure, linux-gcp…): siga la línea que corresponda al sufijo que muestra uname -r, no la del paquete linux por defecto.
Instale después con sudo apt upgrade (Debian, Ubuntu) o sudo dnf upgrade kernel (RHEL, AlmaLinux, Rocky), reinicie con sudo reboot y compruebe con uname -r que la cadena en ejecución coincide con el kernel corregido anunciado. Si sigue coincidiendo con el antiguo, el reinicio no ha pasado al kernel nuevo: revise la entrada de arranque por defecto antes de dar el servidor por corregido. Anote por último el número instalado en su cuaderno.
La documentación oficial
Ficha de Ubuntu de CVE-2026-98432 (publicada el 15 de octubre de 2026, actualizada el 29 de octubre de 2026): https://ubuntu.com/security/CVE-2026-98432
Ficha de Red Hat de CVE-2026-98432 (CVSS 8,1, Bugzilla 2553390): https://access.redhat.com/security/cve/CVE-2026-98432
Ambas fichas se consultaron el 30 de octubre de 2026; pueden haber cambiado desde entonces.
