Dirty Frag en el kernel Linux: qué saber y cómo corregirlo

Shared FAQ page chrome (breadcrumb, dates, read time, «Siga leyendo», enquiry block, category labels): see INDEX-AND-CHROME.md. Translate once.

Última actualización: 9 de mayo de 2026

Resumen

Se ha divulgado una vulnerabilidad de escalada local de privilegios del kernel Linux conocida como Dirty Frag. Se registra principalmente como:

• CVE-2026-43284: IPsec ESP / esp4 / esp6
• CVE-2026-43500: RxRPC / rxrpc

Dirty Frag puede permitir que un usuario local sin privilegios obtenga privilegios de root. No es un exploit remoto de red directo, pero es grave para los servidores de hosting porque un atacante puede obtener primero un acceso limitado a través de un sitio web comprometido, una cuenta SSH/SFTP, una carga de trabajo en contenedor o una cuenta de usuario local. cPanel confirma que el problema afecta al propio kernel Linux y está presente en múltiples distribuciones. (cPanel Support)

---

Sistemas afectados

Dirty Frag afecta a múltiples distribuciones Linux y ramas de kernel. Entre las plataformas afectadas confirmadas están:

• AlmaLinux 8, 9, 10
• Rocky Linux 8, 9, 10
• CloudLinux 7 Hybrid, 8, 9, 10
• Red Hat Enterprise Linux 8, 9, 10
• Ubuntu 20.04, 22.04, 24.04 y otras versiones de Ubuntu con soporte
• Sistemas Oracle Linux que usan kernels RHCK o UEK afectados
• Otras distribuciones Linux con versiones de kernel afectadas

CloudLinux confirma que CloudLinux 7 estándar no está afectado, mientras que CloudLinux 7 Hybrid, 8, 9 y 10 sí lo están. CloudLinux 9 y 10 usan la rama de kernel de AlmaLinux. (CloudLinux Blog)

---

Acción requerida

La corrección recomendada es instalar el kernel parcheado del proveedor y reiniciar el servidor.

Compruebe el kernel actual:

uname -r

Después de actualizar y reiniciar, verifique de nuevo:

uname -r

Instalar el paquete del kernel por sí solo no basta. El servidor debe arrancar con el kernel parcheado.

---

Instrucciones de actualización por sistema operativo

AlmaLinux 8 / 9 / 10

Actualice el kernel:

dnf clean metadata
dnf update 'kernel*' -y
reboot

Verifique:

uname -r
rpm -q kernel

Versiones parcheadas esperadas:

AlmaLinux 8:  kernel-4.18.0-553.123.2.el8_10 or newer
AlmaLinux 9:  kernel-5.14.0-611.54.3.el9_7 or newer
AlmaLinux 10: kernel-6.12.0-124.55.2.el10_1 or newer

AlmaLinux confirma estas versiones de kernel parcheadas en su aviso sobre Dirty Frag. (AlmaLinux OS)

---

CloudLinux

CloudLinux 7 Hybrid / 8

Si el kernel parcheado está disponible en los repositorios estables:

yum update 'kernel*' -y
reboot
uname -r

Si el kernel parcheado solo está disponible en el repositorio de testing/beta:

Para CloudLinux 8:

yum --enablerepo=cloudlinux-updates-testing update 'kernel*' -y
reboot
uname -r

Para CloudLinux 7 Hybrid:

yum --enablerepo=cl7h_beta update 'kernel*' -y
reboot
uname -r

Versiones parcheadas esperadas:

CloudLinux 7 Hybrid: kernel-4.18.0-553.123.2.lve.el7h or newer
CloudLinux 8:        kernel-4.18.0-553.123.2.lve.el8 or newer

CloudLinux indica estas versiones objetivo para las ramas de kernel parcheadas CL7h y CL8. (CloudLinux Blog)

---

CloudLinux 9 / 10

CloudLinux 9 y 10 usan la rama de kernel de AlmaLinux. Si el kernel parcheado está disponible en los repositorios estables:

dnf update 'kernel*' -y
reboot
uname -r

Versiones parcheadas esperadas:

CloudLinux 9:  kernel-5.14.0-611.54.3.el9_7 or newer
CloudLinux 10: kernel-6.12.0-124.55.2.el10_1 or newer

Si el kernel parcheado aún no es visible en los repositorios estables o en los mirrors locales, use temporalmente el repositorio de testing de AlmaLinux.

Para CloudLinux 10:

dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm
dnf update 'kernel*' -y
reboot

Tras el reinicio:

uname -r
dnf config-manager --disable almalinux-testing

Para CloudLinux 9:

dnf install -y https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-1.el9.noarch.rpm
dnf update 'kernel*' -y
reboot

Tras el reinicio:

uname -r
dnf config-manager --disable almalinux-testing

Use el repositorio de testing únicamente para actualizar los paquetes del kernel y desactívelo inmediatamente después de verificar. CloudLinux documenta este flujo temporal con el repositorio de testing para CL9 y CL10. (CloudLinux Blog)

---

RHEL / Rocky Linux / Oracle Linux

En sistemas de la familia RHEL:

dnf clean all
dnf update 'kernel*' -y
reboot

En sistemas Oracle Linux que usan UEK, actualice también los paquetes UEK:

dnf update 'kernel*' 'kernel-uek*' -y
reboot

Verifique:

uname -r
rpm -q kernel kernel-core kernel-uek 2>/dev/null

Red Hat confirma que Dirty Frag afecta a RHEL 8, 9, 10 y OpenShift 4, y recomienda actualizar el kernel o mitigar según la disponibilidad de parches. (Red Hat Customer Portal)

---

Ubuntu / Debian

Actualice el kernel del sistema:

apt update
apt full-upgrade -y
reboot

Verifique:

uname -r
dpkg -l | grep linux-image

Ubuntu confirma que la corrección se distribuye a través de los paquetes de imagen del kernel Linux y recomienda reiniciar con el kernel actualizado. (Ubuntu)

---

SUSE / openSUSE

Actualice el kernel:

zypper refresh
zypper update kernel-default
reboot

Verifique:

uname -r
rpm -qa | grep kernel

---

Mitigación temporal

Si todavía no hay disponible un kernel parcheado o un livepatch, bloquee los módulos afectados:

cat > /etc/modprobe.d/dirtyfrag.conf <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

rmmod esp4 esp6 rxrpc 2>/dev/null || true

Verifique:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

Esta mitigación bloquea esp4, esp6 y rxrpc, que son las rutas de módulo de kernel afectadas. CloudLinux, Ubuntu y Red Hat documentan este bloqueo de módulos como mitigación temporal. (CloudLinux Blog)

---

Advertencia importante

No aplique esta mitigación sin revisarla en sistemas que usen:

• IPsec
• StrongSwan
• Libreswan
• Pasarelas VPN
• Cargas de trabajo AFS / RxRPC

Bloquear esp4 y esp6 puede romper el tráfico IPsec, y bloquear rxrpc puede afectar a las cargas de trabajo AFS/RxRPC. Tanto Ubuntu como Red Hat señalan este impacto operativo. (Ubuntu)

---

Paso adicional para Ubuntu / Debian

En sistemas Ubuntu y Debian, regenere el initramfs después de aplicar la mitigación:

update-initramfs -u -k all

Después verifique de nuevo:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

Ubuntu recomienda regenerar el initramfs para que los módulos afectados sigan bloqueados durante el arranque. (Ubuntu)

---

Vaciar la caché de páginas tras la mitigación

Después de aplicar la mitigación, vacíe la caché de páginas:

sync
echo 3 > /proc/sys/vm/drop_caches

CloudLinux señala que el exploit puede modificar binarios legítimos del sistema en la caché de páginas, por lo que recomienda vaciarla tras la mitigación en sistemas potencialmente atacados. (CloudLinux Blog)

---

Retirar la mitigación después de parchear

Una vez instalado el kernel parcheado y reiniciado el servidor con él:

rm -f /etc/modprobe.d/dirtyfrag.conf

En Ubuntu / Debian:

update-initramfs -u -k all

Reinicie si es necesario:

reboot

---

KernelCare

Si KernelCare está instalado:

kcarectl --update

Verifique la cobertura:

kcarectl --patch-info | grep -E 'CVE-2026-43284|CVE-2026-43500|Dirty Frag'

Si el CVE no aparece en la salida, puede que KernelCare aún no cubra el kernel en ejecución. En ese caso, aplique la actualización de kernel del proveedor o la mitigación temporal. cPanel y CloudLinux mencionan KernelCare como vía de livepatch disponible donde exista cobertura. (cPanel Support)

---

Lista de verificación

Ejecute lo siguiente tras parchear o mitigar:

cat /etc/os-release
uname -r

En sistemas de la familia RHEL:

rpm -q kernel kernel-core kernel-uek 2>/dev/null

En Ubuntu / Debian:

dpkg -l | grep linux-image

Compruebe los módulos afectados:

lsmod | grep -E 'esp4|esp6|rxrpc'

Confirme el estado de la mitigación:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

---

Recomendación de EuroVPS

Restrinja los accesos SSH, SFTP, shell y de panel innecesarios, revise el servidor en busca de sitios web comprometidos, usuarios locales inesperados o escaladas de privilegios, y migre los sistemas operativos en fin de vida.

---

¿Necesita ayuda?

Abra un ticket de soporte desde el área de cliente y, en los servidores donde tenemos acceso root, nuestros ingenieros parchearán o mitigarán y verificarán la corrección.