Dirty Frag es una vulnerabilidad del kernel de Linux que puede permitir que un atacante consiga permisos de administrador, conocidos como permisos root.

Para aprovechar esta vulnerabilidad, el atacante primero necesita tener algún tipo de acceso al sistema, aunque sea con permisos bajos. 

Por ejemplo, podría ser una cuenta de usuario normal, una aplicación comprometida, un contenedor vulnerable o un servicio que ya haya sido atacado.

El problema es que, si el atacante consigue convertirse en root, puede tomar el control completo del sistema.

Con esos permisos podría desactivar herramientas de seguridad, acceder a contraseñas o credenciales, modificar registros del sistema, moverse a otros equipos de la red y mantener el acceso durante más tiempo.

Dónde está el fallo

Linux guarda copias temporales de algunos archivos en memoria para que el sistema funcione más rápido. A esta zona se la conoce como page cache.
En condiciones normales, un usuario no debería poder modificar esas copias si no tiene permisos para cambiar los archivos originales. Sin embargo, Dirty Frag rompe esa protección.

El fallo aparece en ciertas operaciones relacionadas con red y cifrado. El kernel procesa algunos datos directamente en memoria para ganar rendimiento, pero no comprueba correctamente si esa memoria se podía modificar de forma segura. Como resultado, se podían alterar partes de la caché de archivos que deberían estar protegidas.

Linux intentaba ahorrar tiempo procesando datos directamente en memoria, pero esa optimización abría la puerta a modificar información que no debería poder tocarse.

Relación con Copy Fail
Antes de Dirty Frag se hizo pública otra vulnerabilidad parecida llamada Copy Fail, identificada como CVE-2026-31431. Fue divulgada el 29 de abril de 2026.

Copy Fail también permite que alguien con acceso limitado a un sistema Linux pueda conseguir permisos de administrador. En este caso, el fallo está en una parte del kernel relacionada con funciones criptográficas.

El origen del problema fue una mejora de rendimiento introducida en 2017. La idea era evitar copias innecesarias de datos para que el sistema fuera más rápido. Pero esa mejora podía hacer que el kernel modificara zonas de memoria que no deberían ser modificables.

Qué tienen en común
Copy Fail y Dirty Frag pertenecen a la misma familia de problemas.
En ambos casos, el kernel intenta ser más eficiente evitando copiar datos de un sitio a otro. El problema es que, al hacerlo, puede acabar modificando zonas compartidas o protegidas de la memoria.

Esto es especialmente grave porque puede permitir alterar archivos importantes del sistema o binarios especiales que se ejecutan con más privilegios. 

Si se aprovecha correctamente, el atacante puede acabar ejecutando código como root.

Punto importante
Haber aplicado una mitigación contra Copy Fail no significa que el sistema esté protegido contra Dirty Frag.
Son vulnerabilidades relacionadas, pero no son la misma. Por eso, un sistema que ya haya sido protegido frente a Copy Fail puede seguir siendo vulnerable a Dirty Frag.

Gravedad del problema
Dirty Frag no es una vulnerabilidad remota directa. Es decir, no basta con que el equipo esté conectado a Internet para que alguien pueda explotarla sin más.
Aun así, sigue siendo grave. Si un atacante ya ha conseguido entrar en el sistema con pocos permisos, esta vulnerabilidad puede servirle para convertirse en administrador y tomar el control completo del equipo.

Se recomienda:
1.    Identificar todos los sistemas Linux que puedan estar en riesgo, especialmente servidores con usuarios locales, acceso SSH, entornos CI/CD, contenedores, Kubernetes, hosting compartido o cargas de trabajo de terceros.
2.    Aplicar los parches del kernel publicados por cada proveedor y reiniciar los sistemas cuando sea necesario.
3.    Mientras no haya parche disponible, bloquear los módulos esp4, esp6 y rxrpc si no se utilizan.
4.    No asumir que una mitigación aplicada contra Copy Fail protege también contra Dirty Frag.
5.    Revisar la integridad de archivos sensibles y binarios con permisos especiales si existe sospecha de explotación.
6.    Priorizar los sistemas donde un atacante pueda ejecutar código local, aunque sea con permisos limitados.