Dirty Frag (CVE-2026-43284): el error del kernel de Linux que convierte el acceso de lectura en permisos de root

Un archivo de solo lectura debería seguir siendo de solo lectura. Dirty Frag (CVE-2026-43284, CVE-2026-43500 y CVE-2026-46300) consigue que el núcleo de Linux edite de todos modos su copia en caché.

Este error permite que un programa que se ejecuta casi sin privilegios escriba en archivos que solo debería poder leer, modificando la copia que el núcleo mantiene en memoria. A partir de ahí, puede reescribir algo en lo que el sistema confía y otorgarse acceso como root. En entornos de contenedores, el mismo truco que llega al núcleo del host puede alcanzar el núcleo del nodo compartido por cada carga de trabajo.

El patrón vulnerable ha estado en el código de red del núcleo durante años, por lo que abarca a la mayoría de las versiones compatibles del núcleo y a casi todas las distribuciones principales. Linux solucionó el fallo y todas las distribuciones lo adaptaron, por lo que la solución aparecerá bajo un número de versión diferente en cada una de ellas.

Resumen de Dirty Frag

Red Hat agrupa tres CVE bajo Dirty Frag. Se encuentran en diferentes rincones del código de red del núcleo, y uno de ellos es una variante posterior que la primera ronda de parches pasó por alto. Así es como se comparan.

El subsistema te indica si esto es relevante para ti. Si no ejecutas VPN IPsec ni AFS, es una señal rápida para saber cuánto debe importarte. El módulo es lo que comprobarás para (lsmod | grep -E 'esp4|esp6|rxrpc) y ver qué hay cargado.

Linux mantiene en la memoria los datos de los archivos a los que se ha accedido recientemente para no tener que leerlos del disco cada vez. Esa copia en memoria se denomina caché de páginas. Ciertas funciones del kernel como splice() transfieren esos datos en caché al código de red sin copiarlos, pasando en su lugar un puntero a la ubicación donde ya residen los datos. Esto ahorra trabajo, siempre y cuando cada paso posterior sepa que la memoria es compartida y no escriba en ella.

El fallo apareció en dos áreas distintas del código de red del kernel. Una fue ESP, que gestiona el tráfico VPN cifrado. La otra fue RxRPC, un protocolo más antiguo utilizado principalmente por el sistema de archivos AFS. Ni la ruta de ESP ni la de RxRPC comprueban si la memoria es compartida antes de escribir en ella.

Esto permitía a un atacante tomar un archivo de solo lectura que pudiera otorgarle privilegios si era manipulado, algo como /usr/bin/su, e introducir su contenido en la ruta de red para que el descifrado defectuoso terminara escribiendo en la memoria de ese archivo. La escritura acaba en la caché de páginas, que es la copia del archivo que el sistema ofrece a cualquier proceso que lo lea. El archivo en el disco nunca cambia, pero la versión en memoria ahora refleja lo que el atacante haya decidido. Ejecutar su lee la copia alterada y otorga al atacante acceso root, a pesar de que solo se le permitía leer ese archivo.

Fragnesia, registrada como CVE-2026-46300, es la variante más reciente. La solución para Dirty Frag hizo que el kernel dependiera de un marcador que indica "este fragmento es compartido, haz una copia segura antes de modificarlo". Sin embargo, un antiguo error de 2013 en el código que fusiona los fragmentos de paquetes elimina silenciosamente dicho marcador. Permaneció inofensivo durante trece años porque nada dependía de él. Desafortunadamente, la solución de Dirty Frag dependía de él, lo que convirtió un error latente en una nueva vía de acceso root. 

¿Por qué es importante Dirty Frag para los contenedores?

Los contenedores comparten el mismo kernel con el host, por lo que un contenedor vulnerado puede acceder al código vulnerable del kernel si sus permisos lo permiten (configuraciones de llamadas al sistema / namespaces / políticas de seguridad). Los investigadores ya han publicado pruebas de concepto funcionales para Kubernetes, y Ubuntu detalla el riesgo de escape de contenedores. Si el contenedor logra alcanzar el kernel, el riesgo implica obtener acceso root en todo el nodo.

Puedes mitigar parte del ataque ejecutando cargas de trabajo como non-root, activando el perfil de seccomp RuntimeDefault, aplicando políticas de pod restringidas y limitando los espacios de nombres de usuarios sin privilegios. Sin embargo, nada de eso soluciona el fallo real; solo la actualización del kernel del proveedor lo hace.

¿Cómo se puede saber si un servidor está expuesto?

Empieza por el host que está realmente en ejecución, no por el Dockerfile. Hay tres comandos que te pueden ayudar.

Ejecuta uname -r Para averiguar qué versión del núcleo estás utilizando, compárala con la versión corregida que figura en el aviso de seguridad de tu distribución. No la compares con el número del desarrollador original. El patrón vulnerable se remonta a núcleos de alrededor de 2017, y las distribuciones empresariales y LTS, como RHEL, Ubuntu y Debian, retroportan la corrección a la versión más antigua del núcleo que ya estás utilizando, por lo que un núcleo parcheado puede seguir indicando una versión de hace años. Un host RHEL 8 totalmente parcheado sigue indicando la versión 4.18, y esa versión 4.18 ya incluye la corrección. Compruébalo con la versión del paquete corregido de tu proveedor.

lsmod | grep -E 'esp4|esp6|rxrpc Indica si se ha cargado la ruta de código vulnerable. Un resultado vacío no significa que no haya ningún riesgo, ya que estos módulos se cargan bajo demanda. Y el hecho de que se haya cargado no implica automáticamente que sea peligroso. esp4, esp6 y rxrpc son módulos comunes que resultan totalmente seguros en un núcleo parcheado. Esto te permite conocer tu superficie de ataque y determinar si merece la pena aplicar la medida de mitigación de la lista negra.

sysctl user.max_user_namespaces muestra el grado de accesibilidad de la ruta ESP. Un valor superior a cero significa que los usuarios sin privilegios pueden crear espacios de nombres, que es la vía habitual de acceso a la ruta ESP. El valor cero cierra esa puerta, pero solo para ESP. La ruta RxRPC no necesita espacios de nombres, por lo que no ofrece una protección total.

Comprueba el estado de tu proveedor. Red Hat afirma que CVE-2026-43500 no afecta a sus productos, mientras que CVE-2026-43284 y CVE-2026-46300 sí afectan a los núcleos de Red Hat Enterprise Linux para los que ofrece soporte y a cualquier sistema basado en ellos. Ubuntu publica la versión exacta del paquete corregido para cada línea de núcleo para la que ofrece soporte.

¿Qué aspectos debes supervisar?

El código de prueba de concepto ya es público. Microsoft ha informado de una actividad limitada en entornos reales donde un atacante escala privilegios utilizando su, aunque señala con cautela que podría tratarse de Dirty Frag o de su predecesor Copy Fail, ya que es difícil distinguirlos basándose únicamente en los registros de procesos.

El lugar más realista para detectar esto es en las herramientas de auditoría y EDR que ya utilizas. El marco de auditoría de Linux puede registrar la ejecución de procesos y las transiciones de setuid, que es donde aparecería la secuencia reveladora: un binario desconocido que se descarga y ejecuta, seguido inmediatamente por su. Presta atención a la carga de esp4, esp6 o rxrpc al mismo tiempo que otra actividad sospechosa, especialmente en un host que no tiene motivos para usar IPsec o AFS, así como a la ejecución de archivos ELF recién descargados. 

Si sospechas que ha habido una explotación, ejecuta tus comprobaciones de integridad desde un entorno de confianza en lugar de hacerlo desde el propio host posiblemente comprometido. Y recuerda que bloquear los módulos del kernel no deshace los cambios en la caché de páginas que un atacante ya haya realizado.

Dónde encaja Aikido

La mayoría de los análisis se detienen en la imagen o en el repositorio. Dirty Frag se encuentra un nivel más abajo, en el kernel que el nodo realmente arranca.

El escaneo de máquinas virtuales de Aikido Security lee lo que está instalado realmente en el host en ejecución a partir de una instantánea en la nube, por lo que un paquete de kernel vulnerable aparece como un hallazgo del host. Como también vincula los hosts con las cargas de trabajo y las cuentas que se ejecutan en ellos, puedes ver el radio de impacto si un nodo resulta comprometido.

Para los hosts en la nube conectados a Aikido, el escaneo de máquinas virtuales muestra cuáles contienen el paquete de kernel vulnerable y qué cargas de trabajo se ejecutan en ellos. La solución sigue siendo la misma: parchear el kernel del nodo y confirmar la versión cargada tras reiniciar.

{{cta}}

Preguntas frecuentes