- Dirty Frag es una nueva clase de vulnerabilidades en Linux que permite escalar a root manipulando la page cache.
- Encadena dos fallos distintos (xfrm-ESP y RxRPC), afecta a la mayoría de distribuciones modernas y sigue activo incluso con mitigaciones de Copy Fail.
- Ya existe código de prueba público y la revelación se ha adelantado por la rotura de un embargo de seguridad.
- Mientras llegan los parches, se recomiendan mitigaciones como deshabilitar los módulos esp4, esp6 y rxrpc en servidores Linux.
La comunidad de Linux vuelve a estar en alerta máxima tras destaparse una nueva vulnerabilidad de escalada local de privilegios conocida como Dirty Frag. El fallo llega apenas días después del revuelo causado por Copy Fail y se suma a una cadena de problemas graves en el kernel que están poniendo a prueba los mecanismos de seguridad del ecosistema.
Dirty Frag permite que cualquier usuario local sin privilegios pueda convertirse en root en multitud de distribuciones modernas, desde Ubuntu o Debian hasta Fedora, RHEL, AlmaLinux, openSUSE Tumbleweed e incluso entornos como WSL2. Para muchos administradores de sistemas en España y Europa, el descubrimiento supone un quebradero de cabeza más en infraestructuras donde Linux es la base de servidores, servicios cloud y entornos corporativos.
Qué es Dirty Frag y por qué se compara con Dirty Pipe y Copy Fail
Dirty Frag se describe como una nueva clase de vulnerabilidades lógicas en el kernel Linux, emparentada con otros nombres ya conocidos como Dirty Pipe y Copy Fail (CVE-2026-31431). Todas comparten la misma idea de fondo: aprovechar errores en la forma en que el kernel gestiona la page cache, es decir, la copia en memoria de los archivos que se usan con frecuencia para mejorar el rendimiento.
El investigador surcoreano Hyunwoo Kim, conocido como v4bel, ha explicado que el problema no reside tanto en la criptografía o en un desbordamiento clásico, sino en cómo rutas de E/S “zero-copy” dejan páginas de la page cache enganchadas a estructuras internas del kernel y luego aplican operaciones de cifrado o descifrado directamente sobre ellas. Si un usuario sin privilegios consigue que esas páginas apunten a archivos sensibles, el propio kernel acaba escribiendo sobre datos que no deberían poder modificarse.
Desde un punto de vista práctico, Dirty Frag proporciona al atacante una primitiva de escritura sobre la page cache: pequeñas porciones de datos dentro de la copia en RAM de archivos como /usr/bin/su o /etc/passwd pueden alterarse sin permisos de escritura sobre esos archivos en disco. Esa modificación basta, en muchos casos, para conseguir una shell root o dejar la cuenta de superusuario sin contraseña.
Al igual que Dirty Pipe en su día, Dirty Frag destaca por ser determinista, estable y con alta tasa de éxito: no depende de condiciones de carrera, no suele provocar kernel panic cuando falla el intento y se puede empaquetar en un exploit relativamente sencillo de ejecutar.
Dos vulnerabilidades encadenadas: xfrm-ESP y RxRPC Page-Cache Write
Una de las claves de Dirty Frag es que no se trata de un único bug aislado, sino de dos vulnerabilidades complementarias que afectan a subsistemas distintos del kernel: la pila de red IPsec/ESP (xfrm) y el subsistema RxRPC. Ambas comparten el mismo patrón: escrituras sobre la page cache a partir de paquetes de red procesados in-place.
La primera variante, conocida como xfrm-ESP Page-Cache Write (ya asociada al CVE-2026-43284), se encuentra en la ruta de entrada ESP del subsistema XFRM. En determinadas condiciones, cuando llega un paquete ESP y se procesa sin copiar los datos a un búfer privado, el kernel termina descifrando el contenido directamente sobre una página que en realidad es parte de la page cache de un archivo.
El investigador demuestra que, combinando IPsec ESP, ESN y el algoritmo authencesn, es posible lograr escrituras de 4 bytes en posiciones controladas, con un valor también controlado a través de parámetros como seq_hi. El ejemplo más llamativo del análisis consiste en reescribir los primeros 192 bytes de /usr/bin/su en la page cache con un pequeño ELF estático que lanza una shell root, dividido en 48 fragmentos de 4 bytes.
Esta modificación se produce antes de que el kernel termine de verificar la autenticación AEAD del paquete. Aunque la verificación falle y el sistema devuelva un error como -EBADMSG, la escritura en la page cache ya se ha realizado y permanecerá activa hasta que se vacíe la caché o se reinicie la máquina, de modo que una simple llamada posterior a execve("/usr/bin/su") dará acceso completo al sistema.
La segunda variante, denominada RxRPC Page-Cache Write y seguida bajo el identificador CVE-2026-43500, ataca el subsistema RxRPC y el nivel de seguridad RXKAD. En este caso, la función rxkad_verify_packet_1() descifra in-place los primeros 8 bytes del contenido del paquete usando un modo PCBc sobre fcrypt. De nuevo, si el paquete está asociado a una página de la page cache plantada por el atacante mediante splice(), la escritura acaba alterando esa página compartida.
A diferencia del caso ESP, aquí el atacante no controla de forma directa el valor de los 8 bytes escritos, ya que dependen del resultado de fcrypt_decrypt(C, K). Sin embargo, como la clave proviene de una session key que el propio usuario puede registrar con add_key(), es viable hacer fuerza bruta desde espacio de usuario hasta conseguir el efecto deseado.
En el escenario descrito por el investigador, el objetivo no es un binario setuid, sino la primera línea de /etc/passwd. El exploit va reescribiendo bloques de 8 bytes en offsets concretos (4, 6 y 8) hasta dejar la entrada de root con un formato similar a «root::0:0:GGGGGG:/root:/bin/bash», es decir, con el campo de contraseña vacío y aceptado por configuraciones que permitan nullok en PAM.
Un exploit casi universal para distribuciones Linux modernas
Por separado, cada variante de Dirty Frag tiene limitaciones. La ruta xfrm-ESP necesita registrar asociaciones de seguridad XFRM, lo que implica privilegios como CAP_NET_ADMIN. El truco consiste en usar unshare(CLONE_NEWUSER | CLONE_NEWNET) para crear espacios de nombres de usuario y red, de forma que un proceso sin privilegios gane esa capacidad dentro de un namespace aislado.
Sin embargo, algunas distribuciones populares, especialmente en el ámbito de escritorio y servidores en Europa, como ciertas configuraciones de Ubuntu, restringen la creación de namespaces no privilegiados mediante perfiles de AppArmor u otras políticas de seguridad. En esos casos, el camino xfrm-ESP puede quedar bloqueado en la práctica.
Ahí entra en juego la variante RxRPC. Este segundo vector no exige la creación de namespaces de usuario, y se apoya en APIs disponibles para cualquier cuenta estándar, como add_key(), socket(AF_RXRPC), splice(), recvmsg() o incluso socket(AF_ALG). El módulo rxrpc.ko puede cargarse automáticamente al abrir un socket AF_RXRPC, de modo que en entornos donde el módulo está presente —por ejemplo, en varias instalaciones de Ubuntu—, la vía RxRPC sigue siendo perfectamente utilizable.
En otras distribuciones centradas en servidores, como RHEL 10.1 o algunas variantes empresariales usadas en centros de datos europeos, la situación puede invertirse: el módulo RxRPC no se distribuye o no se carga por defecto, pero sí se permite crear namespaces de usuario, de modo que la vía xfrm-ESP continúa siendo viable.
El exploit publicado por el investigador en GitHub combina ambos caminos. Primero intenta el vector ESP en un proceso hijo que invoca unshare(); si consigue modificar /usr/bin/su, el proceso padre simplemente lanza ese binario y obtiene una shell root. Si falla —por ejemplo, porque la creación de namespaces esté denegada o falten los módulos ESP—, entonces prueba la ruta RxRPC contra /etc/passwd y aprovecha la configuración de autenticación para lograr el acceso de administrador.
Esta combinación es lo que ha llevado a describir Dirty Frag como una «universal LPE»: no requiere afinados específicos por distribución, funciona en la mayoría de kernels modernos y se adapta a las peculiaridades de cada sistema, cubriendo los huecos que deja uno u otro vector de ataque.
Versiones de kernel afectadas, parches parciales y relación con Copy Fail
Dirty Frag no aparece en el vacío. Llega justo después de que Copy Fail (CVE-2026-31431) fuera añadida por CISA a su catálogo de vulnerabilidades explotadas activamente, con una tasa de éxito del 100 % en la prueba de concepto pública. Ambos fallos comparten origen temporal y conceptual: optimizaciones introducidas en el kernel a partir de 2017 que priorizan rendimiento y uso de rutas zero-copy sobre la seguridad.
Copy Fail se sitúa en el subsistema criptográfico del kernel, concretamente en el módulo algif_aead de AF_ALG, y permite escribir 4 bytes controlados en la page cache de binarios privilegiados como /usr/bin/su o sudo sin tocar el archivo en disco. La vulnerabilidad afecta a kernels desde la versión 4.11 (2017) hasta las versiones parcheadas en primavera de 2026, lo que supone casi una década de exposición para sistemas sin actualizar.
Dirty Frag, por su parte, se apoya en código que también se remonta a un commit de enero de 2017 en la parte de XFRM, el mismo cambio que ya había provocado en su día CVE-2022-27666, un desbordamiento anterior en el manejo de IPsec. La variante RxRPC deriva de modificaciones introducidas en 2023 en el tratamiento de paquetes RXKAD.
Según explican mantenedores del kernel como Greg Kroah-Hartman, a raíz de Copy Fail se han publicado versiones estables con mitigaciones parciales —como Linux 7.0, 6.18.28, 6.12.87 y 6.6.138— que abordan en mayor o menor medida tanto Copy Fail como los nuevos problemas detectados. Sin embargo, la corrección de Dirty Frag sigue incompleta, especialmente en la parte de RxRPC, donde el parche propuesto aún no se ha integrado por completo en el árbol principal.
Un detalle importante para administradores: las mitigaciones sugeridas para Copy Fail no bastan frente a Dirty Frag. Deshabilitar el módulo algif_aead o activar ciertas políticas de Lockdown evita un tipo concreto de explotación, pero Dirty Frag puede desencadenarse aunque ese módulo esté completamente bloqueado, ya que opera sobre rutas de red y subsistemas diferentes.
Impacto en servidores, cloud y entornos empresariales en Europa
En un contexto donde entre el 70 y el 90 % de las cargas de trabajo en la nube corren sobre Linux, vulnerabilidades como Dirty Frag tienen un impacto directo en empresas tecnológicas, proveedores de hosting, startups y administraciones públicas europeas que dependen de estos sistemas para servicios críticos.
El riesgo principal es la escalada local de privilegios (LPE). Un atacante que consiga un acceso limitado —por ejemplo, mediante una cuenta de usuario comprometida, una aplicación web vulnerable que proporcione una shell restringida o un contenedor Docker mal aislado— puede aprovechar Dirty Frag para convertirse en root en cuestión de segundos, sin necesidad de encadenar varias vulnerabilidades complejas.
En entornos cloud con Kubernetes, OpenShift u otros orquestadores, esto abre la puerta a escapes de contenedores y movimientos laterales entre pods y nodos. El hecho de que la page cache sea compartida entre procesos en el mismo nodo permite, en ciertos escenarios, plantear incluso ataques cross-tenant en infraestructuras multiinquilino si no se han establecido límites estrictos.
Para organizaciones europeas reguladas —desde bancos que corren servicios sobre RHEL o SUSE, hasta proveedores SaaS que usan Ubuntu y Debian en nubes públicas—, Dirty Frag obliga a revisar con urgencia la superficie de ataque. No basta con confiar en que los datos estén cifrados en tránsito o en reposo: si un atacante llega a root en el sistema operativo, puede desactivar controles, manipular registros, extraer secretos de memoria o desplegar malware persistente.
Informes de firmas de ciberseguridad como Unit42 recuerdan que Copy Fail ya figura en el catálogo de vulnerabilidades activamente explotadas por CISA. El hecho de que el exploit de Dirty Frag se publique con advertencias del tipo “no usar en sistemas no autorizados” no reduce en absoluto la probabilidad de abuso, sobre todo cuando el código se puede adaptar e integrar fácilmente en toolkits ofensivos usados por grupos criminales y actores avanzados.
Divulgación acelerada, embargo roto y presión sobre el proceso de parches
La cronología de Dirty Frag ha generado bastante debate en listas de correo técnicas como security@kernel.org, oss-security y netdev. El investigador reportó los detalles de la variante RxRPC a finales de abril y, un día después, informó también de la vulnerabilidad xfrm-ESP, acompañando la descripción de un exploit funcional y parches propuestos.
Inicialmente, la idea era mantener un embargo de varios días para dar margen a los mantenedores del kernel y a las principales distribuciones —Ubuntu, Debian, RHEL, SUSE, Fedora, AlmaLinux, etc.— a preparar actualizaciones coordinadas. Sin embargo, el 7 de mayo un tercero no relacionado publicó información detallada y el exploit para la parte ESP, rompiendo de facto el acuerdo de confidencialidad.
Ante esa situación, y tras consultar con distintos responsables de seguridad de distribuciones, se optó por hacer público el informe completo de Dirty Frag, incluidos diagramas de flujo de explotación, explicaciones sobre la causa raíz y enlaces al repositorio con la prueba de concepto. La consecuencia inmediata ha sido que muchos equipos de seguridad en empresas europeas se han enterado de la vulnerabilidad a la vez que el código de explotación circulaba libremente.
Esta cadena de acontecimientos se suma a la polémica generada por Copy Fail, donde la coordinación entre descubridores, proveedores y comunidad tampoco fue ideal. Mantenedores como Greg Kroah-Hartman han expresado su frustración con los disclosures prematuros que dejan sistemas expuestos antes de que los parches estén ampliamente desplegados, y reclaman procesos más sólidos de gestión de vulnerabilidades en el núcleo de Linux.
Por otro lado, una parte del debate apunta a las herramientas de análisis automatizado y de inteligencia artificial que se están utilizando para revisar código a gran escala. Tanto Copy Fail como Dirty Frag y otros fallos recientes se han detectado gracias a sistemas automáticos capaces de recorrer años de historia del kernel en cuestión de horas, sacando a la luz errores que habrían pasado inadvertidos durante más de una década de revisiones manuales.
Cómo mitigar Dirty Frag mientras llegan las actualizaciones oficiales
En el momento en que se hizo pública la información, no existían parches completos integrados en todas las ramas estables del kernel ni paquetes de actualización listos en los repositorios de las distribuciones. Algunas, como AlmaLinux o proyectos derivados de RHEL, empezaron rápidamente a preparar kernels de prueba con los cambios propuestos, pero para la mayoría de administradores el primer paso pasa por aplicar mitigaciones de configuración.
La recomendación más repetida en la comunidad de seguridad consiste en bloquear los módulos esp4, esp6 y rxrpc, que son los principales implicados en las rutas de descifrado vulnerables. Estos módulos se utilizan sobre todo para IPsec (cifrado de tráfico de red mediante ESP) y para comunicaciones específicas vía RxRPC, lo que significa que muchos servidores web, bases de datos o máquinas de escritorio pueden funcionar sin ellos en el día a día.
Una forma rápida de aplicar esta mitigación es crear una regla de modprobe que reemplace los módulos por un binario inocuo e intente descargarlos si ya están activos. Diversos informes técnicos proponen una línea como la siguiente, que puede ejecutarse en distribuciones basadas tanto en Debian/Ubuntu como en RHEL/Fedora:
sudo sh -c «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; true»
Este comando crea el archivo /etc/modprobe.d/dirtyfrag.conf con reglas que impiden que los módulos vulnerables se vuelvan a cargar, y a continuación intenta descargarlos si ya estaban presentes en el kernel. En la mayoría de despliegos corrientes no debería causar apagones de servicios, pero en entornos que dependan de VPN IPsec basadas en ESP u otras soluciones específicas, es imprescindible evaluar antes el impacto y realizar pruebas en entornos de preproducción.
Más allá de esa medida concreta, los equipos de sistemas y seguridad en España y el resto de Europa están recomendando una serie de pasos adicionales: inventariar qué servidores usan Linux, priorizar aquellos expuestos a internet o con múltiples usuarios, reforzar la configuración de contenedores (namespaces, perfiles de seccomp, SELinux o AppArmor en modo estricto) y vigilar mensajes sospechosos en registros como dmesg relacionados con intentos de explotación.
Herramientas de monitorización de seguridad como Falco, Auditd o soluciones EDR específicas para Linux pueden ayudar a detectar patrones anómalos en el uso de sockets AF_ALG, AF_RXRPC, llamadas a splice() o cargas inusuales de módulos del kernel, aunque, como siempre, la detección no sustituye la necesidad de aplicar parches cuando estén disponibles.
Para responsables técnicos de startups y pymes, que a menudo gestionan infraestructuras en la nube con recursos limitados, la recomendación es clara: tratar las actualizaciones del kernel como una tarea crítica, no como un mantenimiento rutinario más que se puede posponer indefinidamente. Suscribirse a listas de correo de seguridad de las distribuciones, a avisos de CISA y a canales oficiales de proyectos como Debian, Ubuntu, RHEL o SUSE es hoy casi obligatorio.
El encadenamiento de fallos como Dirty Pipe, Copy Fail y ahora Dirty Frag está dejando una sensación incómoda: optimizaciones aparentemente inocuas en rutas de red y E/S, pensadas para exprimir hasta el último ciclo de CPU, pueden convertirse de la noche a la mañana en vectores de ataque que permiten un control total del sistema. Mientras se terminan de integrar los parches en las distintas ramas del kernel y llegan las actualizaciones a los repositorios, deshabilitar los módulos implicados, revisar la superficie de ataque y mantener una vigilancia activa se ha convertido en la estrategia más razonable para reducir el riesgo en entornos basados en Linux.
