¿Qué es exactamente Dirty Frag?

Dirty Frag es el nombre informal de un exploit encadenado que combina dos vulnerabilidades del kernel Linux: CVE-2026-43284 y CVE-2026-43500. La primera ya tiene parche; la segunda aún se está distribuyendo en algunas distros.

La causa raíz de CVE-2026-43284 está en cómo el kernel Linux maneja la memoria de paquetes de red en la ruta IPsec/ESP. Cuando MSG_SPLICE_PAGES adjunta páginas desde un pipe directamente a un buffer de red (skb), las rutas de datagrama IPv4/IPv6 no marcaban esas páginas como compartidas.

El resultado: un paquete ESP-in-UDP construido desde páginas compartidas de pipe parecía al kernel un buffer ordinario de propiedad privada. La desencriptación ESP ocurría in-place directamente sobre memoria que el skb no posee. Un atacante que sabe manipular este comportamiento puede lograr una escritura controlada en la page cache del kernel y, finalmente, escalar a root.

Por qué Dirty Frag es especialmente peligroso

A diferencia de la vulnerabilidad DirtyPipe (2022), que dependía de una condición de carrera estrecha en el manejo de flags de buffer de pipe, Dirty Frag es una falla lógica determinística. El investigador Hyunwoo Kim reporta tasas de éxito muy altas y riesgo mínimo de kernel panic, sin ventana temporal que perder.

Esto lo hace inusualmente confiable como exploit. No requiere suerte: ejecutas el código, obtienes root. Casi siempre.

¿Cómo se conecta con Copy Fail?

Copy Fail (CVE-2026-31431), publicada el 29 de abril, explotaba un bug lógico en el subsistema criptográfico del kernel Linux —específicamente una falla en el template authencesn AEAD que permitía una escritura controlada de 4 bytes en la page cache. Un script de Python de 732 bytes bastaba para obtener root en cualquier distribución Linux mayor construida desde 2017.

Dirty Frag sigue el mismo patrón fundamental —una primitiva de escritura en page cache convertida en escalada a root— pero a través de una ruta de código completamente distinta. Ambas vulnerabilidades convierten optimizaciones de procesamiento in-place de larga vida en primitivas determinísticas de root: Copy Fail por crypto en userspace, Dirty Frag por recepción IPsec.

¿A quién afecta Dirty Frag?

Cada servidor corriendo un kernel Linux mainstream construido desde aproximadamente 2017 en adelante está afectado. La lista completa de distribuciones afectadas incluye:

Por qué importa especialmente para hosting web

Para entornos de hosting, el vector de amenaza es el mismo que con Copy Fail: el atacante no necesita entrar remotamente. El peligro es que una vez que entra —por un plugin vulnerable de WordPress, un web shell, credenciales SSH débiles o un contenedor comprometido— Dirty Frag le permite escalar inmediatamente a root y luego:

• Desactivar herramientas de seguridad y monitoreo
• Leer credenciales almacenadas en el servidor
• Manipular o borrar logs para encubrir su rastro
• Moverse lateralmente a otros sistemas
• Persistir en el servidor más allá de reinicios

Cómo parchear, paso a paso

Paso 1: Actualizar el kernel

Los kernels parcheados están disponibles en repositorios de producción desde el 8 de mayo de 2026. Esta es la única solución real.

Para AlmaLinux, CloudLinux, Rocky Linux, CentOS Stream, RHEL:

sudo dnf clean metadata && sudo dnf upgrade
sudo reboot

Para Debian / Ubuntu:

sudo apt update && sudo apt upgrade
sudo reboot

Para CloudLinux con KernelCare (sin reinicio):

kcarectl --update

Después de reiniciar, confirma que estás corriendo el kernel parcheado:

uname -r
# Compara la salida con la versión parcheada del advisory de tu distro

Paso 2: Mitigación temporal (si no puedes reiniciar ya)

Si un reinicio no es inmediatamente posible, puedes bloquear los módulos vulnerables para que no se carguen. El writeup técnico de Dirty Frag ofrece una mitigación que elimina los módulos con las vulnerabilidades y limpia la page cache:

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
  > /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null
echo 3 > /proc/sys/vm/drop_caches

Después de instalar el kernel parcheado y reiniciar, revierte la mitigación eliminando el archivo /etc/modprobe.d/dirtyfrag.conf.

Paso 3: Combinar con remediación de Copy Fail

Si todavía no has abordado Copy Fail (CVE-2026-31431), trata ambas vulnerabilidades como un único esfuerzo de remediación dado su similitud y solapamiento de pasos. Un solo update de kernel y reinicio cubre las dos. Verifica que tu kernel corriendo esté parcheado para ambas CVEs antes de considerar el servidor limpio.

Comparativa: Dirty Frag vs. Copy Fail vs. DirtyPipe

¿Qué significa esto a futuro?

Dos vulnerabilidades universales de escalada de privilegios en el kernel Linux en ocho días no es normal. Dirty Frag es la segunda en este período, después de Copy Fail. Con prueba de concepto pública publicada antes que los parches y la explotación reducida a un puñado de syscalls estándar, los defensores deben asumir que cualquier foothold local en un host no parcheado puede convertirse en root en segundos.

La divulgación de Dirty Frag también salió mal: una tercera parte no relacionada filtró los detalles del exploit antes de que las distribuciones terminaran de empaquetar los parches, forzando una divulgación pública prematura mientras CVE-2026-43500 seguía sin parche. El mismo patrón que hizo a Copy Fail tan peligroso en sus primeras horas.

Plan de acción operativo

• 1

  Inventario de servidores Linux expuestos

  Lista todos los VPS, dedicados y nodos Kubernetes bajo tu administración. Identifica versión de kernel actual con uname -r.

• 2

  Aplicar update y reiniciar hoy

  Si tienes ventana de mantenimiento, hazlo hoy. Si no, planifica reinicio en las próximas 24-48 horas como máximo.

• 3

  Aplica mitigación temporal donde no puedas reiniciar

  Solo si IPsec no se usa en ese servidor. Documenta cuándo aplicaste la mitigación para revertirla después del reboot.

• 4

  Configura alertas para el próximo CVE

  Suscríbete a los advisories de seguridad de tu distro (Ubuntu Security Notices, Red Hat CVE database, Debian Security Tracker). La próxima vez que esto pase, quieres saberlo en la hora siguiente.

• 5

  Auditoría post-parche

  Revisa logs /var/log/auth.log y /var/log/secure por accesos sospechosos desde finales de abril. Busca procesos extraños, conexiones de red salientes inusuales o archivos sospechosos en /tmp y /dev/shm.