Dirty Frag expone fallas en Linux que permiten escalar a root y alterar archivos críticos

Una investigación técnica reveló Dirty Frag, una nueva clase de vulnerabilidades en Linux que permite a atacantes sin privilegios modificar archivos críticos en la page cache y, en ciertos escenarios, obtener acceso root. La cadena combina fallas en xfrm-ESP y RxRPC, amplía el alcance de problemas vistos en Dirty Pipe y ya dio lugar a CVE-2026-43284 y al seguimiento CVE-2026-43500.
***

• Dirty Frag encadena dos fallas de escritura sobre page cache en Linux, una en xfrm-ESP y otra en RxRPC.
• La variante xfrm-ESP ya fue corregida upstream y recibió CVE-2026-43284, mientras que RxRPC aún no tiene parche upstream y se sigue bajo CVE-2026-43500.
• El exploit puede modificar en RAM archivos como /usr/bin/su o /etc/passwd y lograr privilegios root según la configuración de cada distribución.

Linux enfrenta una nueva alerta de seguridad tras la divulgación de Dirty Frag, una clase de vulnerabilidades que permite escalar privilegios hasta root al encadenar dos fallas distintas de escritura sobre page cache. El hallazgo fue reportado por Hyunwoo Kim, conocido como v4bel, quien además publicó un documento técnico con la causa raíz, el flujo de explotación y los parches propuestos.

El problema afecta a la memoria en caché de archivos a los que un usuario sin privilegios solo debería tener acceso de lectura. Según explicó el investigador, el patrón común consiste en que una ruta zero-copy basada en splice() deja una referencia a una página de page cache en un fragmento de un skb, y luego el kernel realiza criptografía in-place sobre ese mismo fragmento en el lado receptor.

Ese detalle hace que el kernel termine escribiendo sobre la copia en RAM de archivos sensibles. En la práctica, lecturas posteriores pueden observar el contenido alterado, incluso si el archivo real en disco no fue reescrito de inmediato. Entre los objetivos descritos en el análisis figuran /usr/bin/su y /etc/passwd.

La publicación ubica a Dirty Frag en la misma familia conceptual que Dirty Pipe y Copy Fail. La diferencia clave es que Dirty Pipe sobreescribe struct pipe_buffer, mientras Dirty Frag manipula el campo frag de struct sk_buff, lo que abre otra vía para tocar páginas compartidas por el page cache del sistema.

Qué es Dirty Frag y por qué importa

Para lectores menos familiarizados con el tema, la page cache es el mecanismo con el que Linux mantiene en memoria partes de archivos usados recientemente. Esto mejora el rendimiento, pero también implica que una modificación inesperada en esa copia puede afectar la ejecución o lectura de componentes críticos del sistema.

En Dirty Frag, el punto delicado no es la criptografía en sí, sino el hecho de que una operación criptográfica in-place genera escrituras sobre un búfer que el kernel asumía como seguro. Si ese búfer en realidad apunta a una página de page cache plantada por un atacante mediante splice, la escritura termina recayendo sobre datos que no deberían ser modificables por ese usuario.

El autor divide la clase Dirty Frag en dos variantes. La primera es xfrm-ESP Page-Cache Write. La segunda es RxRPC Page-Cache Write. Cada una tiene limitaciones prácticas diferentes, pero al combinarse cubren los puntos ciegos de la otra y permiten que un solo binario de explotación funcione en varias distribuciones Linux.

De acuerdo con el documento técnico enlazado desde GitHub, Dirty Frag puede activarse aunque no esté disponible el módulo algif_aead. Eso significa que sistemas que mitigaron Copy Fail mediante la desactivación o lista negra de ese componente todavía podrían seguir expuestos a esta nueva familia de fallas.

La variante xfrm-ESP y el CVE-2026-43284

La primera variante se apoya en una ruta de entrada ESP dentro del subsistema XFRM de Linux. Antes de descifrar tráfico AEAD de forma in-place, el kernel debería separar o copiar los datos a un búfer privado cuando el skb es no lineal. Sin embargo, el investigador identificó una rama en esp_input() que evita ese copy-on-write bajo determinadas condiciones.

Como resultado, si un atacante logra plantar una página de page cache en el fragmento del skb mediante splice, el descifrado in-place opera con esa página como fuente y destino. El análisis muestra que, en la combinación ESP + ESN + authencesn, ocurre una escritura de 4 bytes en una posición controlable del archivo, y el valor también puede ser controlado por el atacante a través de seq_hi.

La publicación explica que esa escritura se produce antes de que termine la verificación de autenticación AEAD. Por eso, incluso si la autenticación falla y el kernel devuelve un error como -EBADMSG, la modificación en la page cache ya ocurrió y persiste hasta que se limpian cachés o se reinicia el sistema.

En el escenario de explotación descrito, el objetivo es /usr/bin/su. El documento detalla cómo los primeros 192 bytes del archivo son reemplazados en la page cache por un ELF estático de root shell. Esos 192 bytes se dividen en 48 fragmentos de 4 bytes, cada uno escrito con la primitiva de xfrm-ESP. Luego, una sola llamada a execve(“/usr/bin/su”) bastaría para obtener una shell root, omitiendo por completo el flujo PAM.

Esa variante no está abierta de forma universal. Registrar un Security Association de XFRM requiere CAP_NET_ADMIN, por lo que el atacante necesita crear un nuevo espacio de nombres con unshare(CLONE_NEWUSER | CLONE_NEWNET). El texto subraya que eso exige la capacidad de crear espacios de nombres de usuario, un punto que algunas políticas de Ubuntu restringen para procesos sin privilegios.

La buena noticia es que esta variante sí recibió parche upstream. El arreglo final marca con SKBFL_SHARED_FRAG los fragmentos de páginas llegados mediante splice en rutas IPv4 e IPv6 y, en la entrada ESP, fuerza el camino hacia skb_cow_data() cuando se detectan fragmentos compartidos. El parche fue fusionado en netdev el 2026-05-07 y en mainline el 2026-05-08 bajo el commit f4c50a4034e6. A esta vulnerabilidad se le asignó el CVE-2026-43284.

La variante RxRPC y el seguimiento CVE-2026-43500

La segunda variante apunta al subsistema RxRPC, específicamente a la verificación de paquetes en el nivel RXRPC_SECURITY_AUTH de RXKAD. Allí, la función rxkad_verify_packet_1() descifra en el mismo lugar los primeros 8 bytes de la carga útil del skb, usando pcbc(fcrypt).

El punto vulnerable es similar al de xfrm-ESP. skb_to_sgvec() transforma directamente el fragmento del skb en la lista de dispersión usada por la operación criptográfica. Si el atacante plantó una página de page cache mediante splice, el descifrado in-place termina escribiendo 8 bytes sobre esa página.

Aquí hay una diferencia importante. El atacante no controla de forma directa el valor exacto escrito, porque el contenido final es el resultado de fcrypt_decrypt(C, K). Aun así, como la clave K proviene de una session_key de un token RxRPC v1 registrado con add_key(), un usuario sin privilegios puede rotar claves y hacer fuerza bruta en espacio de usuario hasta encontrar una salida útil.

Precisamente por esa limitación, el objetivo descrito no es /usr/bin/su, sino la primera línea de /etc/passwd. El exploit remodela el inicio de la entrada de root para dejarla como “root::0:0:GGGGGG:/root:/bin/bash”. Según la explicación técnica, esto vacía el campo de contraseña y permite que pam_unix.so nullok lo acepte sin solicitar un prompt.

La modificación no ocurre de una sola vez. El diseño usa tres escrituras de 8 bytes en offsets de archivo 4, 6 y 8, aplicando una lógica de last-write-wins. El documento detalla que el atacante debe ajustar el cifrado efectivo en cada etapa porque las escrituras previas cambian el bloque que verán las siguientes operaciones de fuerza bruta.

En este caso no se necesita unshare(), algo crucial para entornos más cerrados. La explotación usa APIs disponibles para usuarios sin privilegios, como add_key(), socket(AF_RXRPC), socket(AF_ALG), splice() y recvmsg(). El módulo rxrpc.ko puede cargarse con un socket dummy AF_RXRPC, gracias al alias de protocolo de red que describe el autor.

El documento indica que todavía no existe un parche upstream para esta variante. El cambio propuesto por el investigador agrega una condición adicional, || skb->data_len, en las compuertas que hoy solo revisan skb_cloned(skb). La idea es copiar también los skb no lineales antes del descifrado in-place. El seguimiento quedó reservado como CVE-2026-43500 el 2026-05-08.

Cómo se encadenan ambas fallas y qué distribuciones quedan peor posicionadas

Uno de los puntos más delicados del trabajo es que ambas variantes se complementan. La de xfrm-ESP ofrece una primitiva más fuerte de escritura arbitraria de 4 bytes, pero exige la creación de espacios de nombres de usuario. La de RxRPC no requiere ese privilegio, aunque depende de que el módulo rxrpc.ko exista y esté disponible en la distribución.

El investigador menciona que Ubuntu a veces bloquea la creación de espacios de nombres de usuario sin privilegios mediante política AppArmor. En ese entorno, el camino xfrm-ESP podría quedar neutralizado. Sin embargo, también señala que en Ubuntu el módulo rxrpc.ko se carga por defecto, lo que da margen a la segunda vía.

En cambio, la compilación por defecto de RHEL 10.1, según el documento, no distribuye rxrpc.ko. Allí la variante RxRPC perdería utilidad, pero podría seguir funcionando xfrm-ESP si el entorno permite el uso de espacios de nombres. La consecuencia es que un exploit encadenado puede adaptarse a los límites del sistema atacado.

El flujo descrito es claro. Primero intenta la variante ESP en un proceso hijo con unshare(USER|NET). Si logra modificar /usr/bin/su, el proceso padre lanza /usr/bin/su y obtiene shell root. Si falla, por ejemplo por -EPERM, por ausencia de esp4.ko o por error al registrar el SA, el binario recurre a la variante RxRPC y modifica /etc/passwd para pasar luego por su vía PAM nullok.

Divulgación, parches y contexto de riesgo

La línea temporal publicada por el autor muestra un proceso de divulgación acelerado y con embargo roto. Para xfrm-ESP, la información detallada y un exploit funcional fueron enviados a security@kernel.org el 2026-04-30. Ese mismo día se mandó un parche a la lista netdev y la información del problema quedó expuesta públicamente.

Luego, el 2026-05-04, Kuan-Ting Chen envió el enfoque alternativo basado en shared-frag. El 2026-05-07 el parche fue integrado en netdev. Ese mismo día se compartieron detalles con la lista linux-distros bajo un embargo de 5 días, con la condición de que si un tercero publicaba el exploit durante ese período, Dirty Frag sería revelado por completo.

Según la cronología, eso fue exactamente lo que ocurrió. El 2026-05-07, un tercero no relacionado publicó información detallada y el exploit de la vulnerabilidad ESP, lo que rompió el embargo. Tras consultar a mantenedores de distribuciones, el autor publicó el documento completo de Dirty Frag.

Para la variante RxRPC, la divulgación detallada y el exploit fueron enviados a security@kernel.org el 2026-04-29, un día antes de la presentación de xfrm-ESP. El parche para RxRPC también fue remitido a netdev el 2026-04-29, pero, a diferencia del caso ESP, todavía no existe una corrección upstream integrada.

La fuente original destaca que Dirty Frag no debe leerse solo como un bug aislado, sino como otra señal de riesgo en rutas zero-copy y en operaciones criptográficas in-place sobre estructuras del kernel que pueden terminar apuntando a memoria compartida. Desde una perspectiva de seguridad defensiva, eso obliga a revisar no solo módulos concretos, sino patrones de diseño más amplios.

Para administradores y equipos de infraestructura, la prioridad inmediata pasa por verificar si el sistema incorporó el parche para CVE-2026-43284, evaluar la exposición al subsistema RxRPC y revisar políticas sobre espacios de nombres de usuario, carga de módulos y superficie disponible para splice(). En entornos multiusuario, la posibilidad de convertir acceso local sin privilegios en root hace que el impacto potencial sea especialmente alto.

GitHub aloja el documento técnico completo y el autor detalla tanto el exploit como las mitigaciones, una señal de que la ventana entre divulgación y abuso potencial podría ser corta. Para el ecosistema Linux, Dirty Frag vuelve a poner sobre la mesa una lección incómoda: optimizaciones de rendimiento aparentemente inocuas pueden convertirse en rutas directas hacia compromisos críticos del sistema.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín