Vulnerabilidad del kernel Linux CVE-2026-98432: bloqueo temporal y aplicación del parche del kernel
CVE-2026-98432 es una vulnerabilidad del kernel Linux en la que el código del kernel que acepta conexiones TCP IPv4 vuelve a leer memoria ya liberada, y el equipo CVE del kernel Linux la calificó como Critical. Como es un fallo que se puede atacar en remoto sin autenticación, actualizamos un servidor Lightsail con AlmaLinux 9.8, Nginx y Apache a los paquetes del kernel corregido, lo reiniciamos y comprobamos el parche con la versión del kernel en ejecución.
1️⃣ Vulnerabilidad del kernel Linux CVE-2026-98432: cómo funciona el fallo y a qué afecta
Cuando llega una solicitud de conexión TCP (SYN) con opciones IPv4, el kernel guarda una copia de esas opciones junto con la conexión en espera para devolverlas en su respuesta (SYN-ACK). Cuando la conexión se establece, esta copia pasa tal cual al socket de la nueva conexión, sin duplicarse.
Si entretanto el cliente vuelve a enviar el SYN, otra CPU puede estar construyendo un SYN-ACK con las mismas opciones. Si en ese momento la nueva conexión se cierra y el kernel libera enseguida la memoria de las opciones, el código que construía el SYN-ACK lee memoria ya liberada: un use-after-free.
Este código se ejecuta mientras el kernel procesa la solicitud de conexión, antes de que la aplicación vea la conexión. Por eso, sea cual sea el servicio que abrió el puerto, si escucha por TCP IPv4, un ataque puede alcanzarlo en remoto sin credenciales, y la puntuación es 9.8 según CVSS 3.1.
El fallo existe desde Linux 4.4, así que afecta a la mayoría de los servidores Linux. Entre los blueprints de Lightsail, la guía de AWS menciona AlmaLinux 9, CentOS Stream 9, Debian, openSUSE Leap, Ubuntu, Amazon Linux 2 y Amazon Linux 2023. El anuncio de AlmaLinux incluye las versiones 8, 9 y 10, y los blueprints de aplicaciones de Lightsail como WordPress y LAMP se ejecutan sobre Debian o Ubuntu, así que también están afectados.
FreeBSD y Windows Server, que no usan el kernel Linux, quedan fuera.
Los servidores con MPTCP (Multipath TCP) desactivado también necesitan el parche. El ataque publicado apuntaba a servidores con un listener MPTCP abierto, pero el fallo está en el código TCP IPv4 normal, por lo que el anuncio de AlmaLinux indica que los sistemas sin MPTCP también deben corregirse.
El kernel corregido libera la memoria de las opciones solo después de que pase un periodo de gracia de RCU (grace period), de modo que la memoria se mantiene mientras otra CPU lee las opciones para construir un SYN-ACK.
2️⃣ Comprobar la versión del kernel Linux: ¿es un kernel corregido?
Si hace falta el parche depende de la versión del kernel en ejecución, así que antes de actualizar comprobamos primero la distribución y la versión del kernel.
cat /etc/os-releaseNAME="AlmaLinux"
VERSION="9.8 (Olive Jaguar)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.8"
PLATFORM_ID="platform:el9"
PRETTY_NAME="AlmaLinux 9.8 (Olive Jaguar)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:9::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"
ALMALINUX_MANTISBT_PROJECT="AlmaLinux-9"
ALMALINUX_MANTISBT_PROJECT_VERSION="9.8"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.8"
SUPPORT_END=2032-06-01uname -r5.14.0-687.55.1.el9_8.x86_64nft --version-bash: nft: command not foundLa distribución era AlmaLinux 9.8 y el kernel en ejecución era 5.14.0-687.55.1.el9_8. Tampoco existía el comando nft que usa la regla de bloqueo temporal, así que el paquete nftables no estaba instalado.
rpm -q kernelkernel-5.14.0-611.30.1.el9_7.x86_64
kernel-5.14.0-687.49.1.el9_8.x86_64
kernel-5.14.0-687.55.1.el9_8.x86_64[rpm -q kernel] muestra la lista de kernels instalados, pero hasta que reinicies el único que funciona de verdad es el que aparece en [uname -r]. Compara esta versión con la versión corregida del anuncio de AlmaLinux.
| Distribución | Versión del kernel corregido (esta versión o superior) |
|---|---|
| AlmaLinux 8 | kernel-4.18.0-553.182.1.el8_10 |
| AlmaLinux 9 | kernel-5.14.0-687.64.1.el9_8 |
| AlmaLinux 10 | kernel-6.12.0-211.72.1.el10_2 |
5.14.0-687.55.1.el9_8 era inferior a 5.14.0-687.64.1.el9_8, la versión corregida de AlmaLinux 9, así que había que actualizar.
Para ver si el ataque tenía un camino abierto, comprobamos los puertos TCP IPv4 en escucha y el estado de MPTCP.
ss -lnt4State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 511 0.0.0.0:443 0.0.0.0:*
LISTEN 0 511 0.0.0.0:80 0.0.0.0:*sysctl net.mptcp.enablednet.mptcp.enabled = 0ss -lnMState Recv-Q Send-Q Local Address:Port Peer Address:PortLos puertos TCP IPv4 que escuchaban en todas las direcciones (0.0.0.0) eran el 80 y el 443 del servidor web y el 22 de SSH.
[net.mptcp.enabled] era 0 y no había sockets MPTCP, así que la vía MPTCP que usó el ataque publicado estaba cerrada. Aun así, el fallo empieza en las conexiones TCP IPv4 normales, por lo que un servidor que escucha en tres puertos IPv4 sigue necesitando el parche.
3️⃣ Actualizar el kernel Linux: siete paquetes del kernel y un reinicio
Antes de cambiar el kernel, creamos una instantánea manual de la instancia en la consola de Lightsail. Lightsail no tiene ninguna pantalla para elegir el kernel de arranque, así que si el servidor no arranca con el nuevo kernel, se restaura creando una instancia nueva a partir de esta instantánea.
🔲 Simulador de instantáneas de Lightsail
Linux 기반 블루프린트를 사용하는 인스턴스에 취약점(CVE-2026-98432)이 발생할 수 있습니다. 인스턴스가 영향을 받는지 확인하고 사용 중인 Linux 배포판에 최신 보안 업데이트를 적용하는 것이 좋습니다.
(us-east-1a)
스냅샷을 생성하여 인스턴스, 해당 시스템 디스크 및 연결된 디스크를 백업할 수 있습니다.
일일 스냅샷 시간은 오전 5:00 GMT+0입니다.Amazon은 가장 최근의 스냅샷 7개를 저장합니다.
🔲 Comprobar la actualización del kernel Linux y el reinicio
Comprobamos la versión del kernel corregido publicada en el repositorio con un listado de dnf.
dnf --showduplicates list available kernel kernel-core kernel-modules kernel-modules-core kernel-tools kernel-tools-libs kernel-headerskernel.x86_64 5.14.0-687.64.1.el9_8 baseos
kernel-core.x86_64 5.14.0-687.64.1.el9_8 baseos
kernel-modules.x86_64 5.14.0-687.64.1.el9_8 baseos
kernel-modules-core.x86_64 5.14.0-687.64.1.el9_8 baseos
kernel-tools.x86_64 5.14.0-687.64.1.el9_8 baseos
kernel-tools-libs.x86_64 5.14.0-687.64.1.el9_8 baseos
kernel-headers.x86_64 5.14.0-687.64.1.el9_8 appstreamdnf download kernel-core-5.14.0-687.64.1.el9_8Descarga solo el archivo del paquete kernel-core en la carpeta actual, sin instalarlo.
rpm -Kv kernel-core-5.14.0-687.64.1.el9_8.x86_64.rpm V4 RSA/SHA256 Signature, key ID b86b3716: OKrpm -qp --changelog kernel-core-5.14.0-687.64.1.el9_8.x86_64.rpm | grep CVE-2026-98432- ipv4: free inet_opt and ireq_opt after an RCU grace period (CKI Backport Bot) [RHEL-295635] {CVE-2026-98432}La firma era OK y el registro de cambios tenía una línea que corregía CVE-2026-98432. Los avisos de seguridad de dnf (updateinfo) que consultamos el 3 de noviembre todavía no incluían este CVE, así que con [dnf upgrade --security] no se podía obtener este kernel.
Por eso instalamos los siete paquetes del kernel indicando también la versión.
dnf install -y kernel-5.14.0-687.64.1.el9_8 kernel-core-5.14.0-687.64.1.el9_8 kernel-modules-5.14.0-687.64.1.el9_8 kernel-modules-core-5.14.0-687.64.1.el9_8 kernel-tools-5.14.0-687.64.1.el9_8 kernel-tools-libs-5.14.0-687.64.1.el9_8 kernel-headers-5.14.0-687.64.1.el9_8================================================================================
Package Architecture Version Repository Size
================================================================================
Installing:
kernel x86_64 5.14.0-687.64.1.el9_8 baseos 1.1 M
kernel-core x86_64 5.14.0-687.64.1.el9_8 baseos 17 M
kernel-modules x86_64 5.14.0-687.64.1.el9_8 baseos 40 M
kernel-modules-core x86_64 5.14.0-687.64.1.el9_8 baseos 31 M
Upgrading:
kernel-headers x86_64 5.14.0-687.64.1.el9_8 appstream 2.6 M
kernel-tools x86_64 5.14.0-687.64.1.el9_8 baseos 1.3 M
kernel-tools-libs x86_64 5.14.0-687.64.1.el9_8 baseos 1.1 M
Removing:
kernel x86_64 5.14.0-611.30.1.el9_7 @baseos 0
kernel-core x86_64 5.14.0-611.30.1.el9_7 @baseos 64 M
kernel-modules x86_64 5.14.0-611.30.1.el9_7 @baseos 33 M
kernel-modules-core x86_64 5.14.0-611.30.1.el9_7 @baseos 27 M
Transaction Summary
================================================================================
Install 4 Packages
Upgrade 3 Packages
Remove 4 Packages
Total download size: 94 M
Complete!Se instalaron cuatro paquetes del kernel nuevo, se actualizaron los tres paquetes kernel-headers, kernel-tools y kernel-tools-libs, y no cambió ningún otro paquete. Como el ajuste [installonly_limit=3] conserva hasta tres kernels instalados, se eliminaron los cuatro paquetes del más antiguo, 5.14.0-611.30.1.el9_7, y desde la descarga hasta el final pasaron 74 segundos.
El comando oficial que indica el anuncio de AlmaLinux vuelve a descargar la información de los repositorios y luego actualiza todos los paquetes que tengan actualización.
sudo dnf clean metadata && sudo dnf upgradeComo también se actualizan otros paquetes además del kernel, los pasos para subir toda la versión de la distribución están en Actualización de Alma Linux: 9.4 → 9.8 en LightSail.
El nuevo kernel solo se aplica después de reiniciar.
systemctl rebootCuando el servidor volvió a arrancar, comprobamos por orden el kernel en ejecución, los kernels instalados y el kernel predeterminado.
uname -r5.14.0-687.64.1.el9_8.x86_64rpm -q kernelkernel-5.14.0-687.49.1.el9_8.x86_64
kernel-5.14.0-687.55.1.el9_8.x86_64
kernel-5.14.0-687.64.1.el9_8.x86_64grubby --default-kernel/boot/vmlinuz-5.14.0-687.64.1.el9_8.x86_64El servidor volvió a arrancar en menos de un minuto tras el comando de reinicio, y tanto el kernel en ejecución como el kernel predeterminado del siguiente arranque pasaron a ser 5.14.0-687.64.1.el9_8. El kernel anterior, 5.14.0-687.55.1.el9_8, sigue instalado, así que si el nuevo kernel da problemas puedes volver a poner el anterior como predeterminado.
| Categoría | Antes del parche | Después del parche |
|---|---|---|
| Kernel en ejecución (uname -r) | 5.14.0-687.55.1.el9_8 | 5.14.0-687.64.1.el9_8 |
| Kernel predeterminado (grubby) | 5.14.0-687.55.1.el9_8 | 5.14.0-687.64.1.el9_8 |
| Kernels instalados (rpm -q kernel) | 5.14.0-611.30.1.el9_7, 5.14.0-687.49.1.el9_8, 5.14.0-687.55.1.el9_8 | 5.14.0-687.49.1.el9_8, 5.14.0-687.55.1.el9_8, 5.14.0-687.64.1.el9_8 |
4️⃣ Bloqueo temporal antes de reiniciar: reglas nft y sus límites
Si no puedes reiniciar enseguida, puedes bloquear con una regla temporal los paquetes que desencadenan el fallo hasta instalar el kernel corregido. Los comandos de esta sección no los ejecutamos nosotros; siguen la guía oficial (los anuncios de AlmaLinux y de AWS).
En el servidor Lightsail con AlmaLinux 9.8, Nginx y Apache, un reinicio tarda solo unos minutos, así que actualizamos el kernel directamente, sin bloqueo temporal.
El fallo solo se desencadena con solicitudes de conexión TCP que llevan opciones IPv4. El tráfico normal casi no usa opciones IPv4, así que si bloqueas solo los paquetes TCP IPv4 con opciones, las conexiones habituales siguen funcionando igual.
sudo dnf install -y nftablesEl comando nft está en el paquete nftables, que se instala junto con firewalld. Si tu servidor no tiene el comando, instálalo primero.
sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
chain prerouting {
type filter hook prerouting priority -300; policy accept;
meta l4proto tcp ip hdrlength > 5 counter drop
}
}
EOFCrea una tabla que descarta en la etapa prerouting los paquetes TCP cuya longitud de cabecera IPv4 es mayor que 5, es decir, los paquetes con opciones IPv4. Es una regla que AlmaLinux probó en 8, 9 y 10; se puede usar junto con firewalld y es seguro ejecutarla varias veces.
sudo nft list table ip cve_2026_98432Comprueba que la regla está puesta; el valor de counter en la salida es el número de paquetes bloqueados hasta ahora.
sudo nft delete table ip cve_2026_98432Después de reiniciar con el kernel corregido, borra la tabla con este comando.
Esta regla desaparece al reiniciar, así que si reiniciaste antes de instalar el kernel corregido, vuelve a ejecutar el comando que crea la tabla.
Esta regla no es adecuada para servidores con aplicaciones que dependen de las opciones IPv4. Un ejemplo son las redes que usan etiquetas de seguridad CIPSO (NetLabel), que viajan en las opciones IPv4; en la configuración predeterminada no se usan.
La regla protege el host y los contenedores que reciben el tráfico a través del host (el modo predeterminado de Podman y Docker). El tráfico que intercambian los contenedores de un mismo host puede saltarse esta regla.
En Debian, Ubuntu y openSUSE se usa la regla de iptables de una línea de la guía de AWS. Los kernels de AlmaLinux 9 y CentOS Stream 9 no tienen el match u32 que usa esta regla, así que en ellos se usa la regla nft de arriba.
sudo iptables -I INPUT 1 -p tcp -m u32 --u32 '0>>24&0x0f=6:15' -j DROPLa expresión u32 lee el campo de longitud de la cabecera IPv4; si el valor es mayor que 5, el paquete lleva opciones IPv4. Después de instalar el kernel corregido, borra esta regla con el comando de abajo.
sudo iptables -D INPUT -p tcp -m u32 --u32 '0>>24&0x0f=6:15' -j DROPCerrar en el firewall de Lightsail los puertos que no usas y limitar los demás a direcciones IP de confianza es otra medida que recomienda la guía de AWS.
🔢 FAQ & contenido recomendado
Versión del kernel
Comandos para comprobar la versión del kernel Linux y cómo ver la versión de la distribución
En Linux, la versión del kernel se comprueba con el comando uname.
ℹ️ Aviso de afiliados
El contenido de este sitio incluye enlaces de afiliado. Cuando un visitante compra un producto o servicio a través de uno de ellos, el sitio recibe una comisión del vendedor. El importe que paga el comprador(baja durante las promociones ↓)no aumenta. Los precios, descuentos y existencias publicados corresponden al momento de redacción y pueden variar, así que confírmalos con el vendedor antes de comprar. Los productos se eligen y evalúan con criterios propios, y las comisiones no influyen en el orden ni en el contenido de las reseñas.