Dirty Frag — una nueva vulnerabilidad de elevación local de privilegios en el kernel Linux, aún sin corregir, que permite a cualquier usuario local obtener derechos de root en la mayoría de las distribuciones más populares (Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44, entre otras), mientras que la medida de protección temporal estándar frente a Copy Fail (CVE-2026-31431) no funciona: se ha publicado un proof-of-concept funcional, la explotación se ejecuta con un solo comando y, hasta la publicación de parches, la única medida práctica sigue siendo bloquear los módulos esp4, esp6 y rxrpc.

Detalles técnicos de Dirty Frag

El investigador Hyunwoo Kim describe Dirty Frag como una evolución del mismo tipo de errores lógicos en el kernel al que pertenecen las vulnerabilidades Dirty Pipe y Copy Fail (CVE-2026-31431, CVSS 7.8). La característica clave de esta clase es un error lógico determinista sin condición de carrera:

• no se requiere una race condition ni acertar con precisión en el timing;
• si el intento de explotación falla, el kernel no se cae (no hay panic);
• la probabilidad de una elevación de privilegios exitosa se aproxima al 100 % en una configuración adecuada.

Dirty Frag se basa en la combinación de dos errores distintos de escritura en la caché de páginas del kernel: xfrm-ESP Page-Cache Write y RxRPC Page-Cache Write. Ambos errores permiten modificar de forma incorrecta datos en la caché de páginas que siguen estando bajo el control de un proceso no privilegiado. Este es un escenario clásico de explotación de una vulnerabilidad del tipo Exploit for Privilege Escalation (T1068) según MITRE ATT&CK.

xfrm-ESP Page-Cache Write: primitiva de escritura de 4 bytes a través de IPSec

El primer componente es una vulnerabilidad en la subsistema IPSec (xfrm), designada por el investigador como xfrm-ESP Page-Cache Write. El error:

• apareció tras un commit de enero de 2017;
• correlaciona con el mismo cambio que provocó el desbordamiento de búfer CVE-2022-27666 (CVSS 7.8), descrito en la NVD para CVE-2022-27666;
• proporciona al atacante una primitiva de escritura de 4 bytes en la caché de páginas del kernel, similar en potencia a la utilizada en Copy Fail.

Esta parte del exploit se apoya en el funcionamiento de ESP en combinación con la caché de páginas: al procesar tráfico IPSec (a través de la interfaz XFRM user netlink) el kernel realiza operaciones de descifrado «in place» sobre páginas que pueden estar respaldadas por objetos externos (por ejemplo, páginas de un canal adjuntas mediante splice() o sendfile()). En este proceso es posible escribir sobre datos a los que todavía mantiene una referencia un proceso no privilegiado.

Limitación crítica: para explotar la variante xfrm-ESP se requiere la capacidad de crear user namespaces. En Ubuntu esto se bloquea por defecto mediante perfiles de AppArmor, por lo que en dicha configuración esta vía de explotación no está disponible.

RxRPC Page-Cache Write: evasión de la prohibición de crear namespaces

El segundo componente es RxRPC Page-Cache Write. Apareció en el kernel más tarde, tras un commit de junio de 2023, y repite el mismo patrón defectuoso en la ruta de descifrado, pero:

• no requiere privilegios para crear user namespaces;
• utiliza el módulo rxrpc.ko, que falta en la distribución estándar de muchas distribuciones (por ejemplo, RHEL 10.1), pero se carga por defecto en Ubuntu.

Desde el punto de vista técnico, el error es análogo: la subsistema RxRPC, igual que esp4/esp6, realiza el descifrado «in place» sobre páginas que no son completamente privadas para el kernel. Como resultado, los datos en texto claro o las propias estructuras del kernel ubicadas en esas páginas pueden ser corrompidos por código de un proceso no privilegiado.

Cadena de explotación: solapamiento mutuo de las «zonas ciegas»

El hallazgo de ingeniería clave de Dirty Frag es la combinación de dos vulnerabilidades de forma que cada una cubra las limitaciones de la otra:

• en entornos donde está permitido crear user namespaces pero el módulo rxrpc.ko no está disponible o no se carga, se emplea la variante xfrm-ESP;
• en entornos como Ubuntu, donde AppArmor bloquea la creación de user namespaces pero rxrpc.ko está habilitado por defecto, se explota la variante RxRPC.

De este modo, para la mayoría de las distribuciones masivas existe al menos una vía de explotación funcional y, en algunas configuraciones, ambas. El investigador subraya que Dirty Frag puede explotarse con éxito independientemente de si el módulo algif_aead está activo. Es decir, incluso los sistemas donde Copy Fail supuestamente está «cerrado» mediante el bloqueo de algif_aead siguen siendo vulnerables a la nueva técnica.

Contexto de amenaza y relación con Copy Fail

Copy Fail (CVE-2026-31431), la vulnerabilidad precedente de la misma clase, ya se explota activamente en ataques reales, según los datos del investigador. Este es un indicador importante: en cuanto aparece un exploit público para esta categoría de errores lógicos en las subsistemas de procesamiento de datos de red, los atacantes lo integran rápidamente en sus cadenas — desde web shells hasta escapes de contenedores.

Dirty Frag hereda varias propiedades indeseables de Copy Fail y Dirty Pipe:

• vector de ataque local, pero con un umbral de entrada extremadamente bajo (PoC listo y ejecución en un solo comando);
• universalidad: las mismas primitivas de escritura se aplican a distintos objetivos en memoria (sustitución de binarios, modificación de /etc/passwd o /etc/shadow, inyección en procesos de seguridad, etc.);
• ausencia de fallos visibles en el kernel en caso de explotación fallida, lo que complica la detección basada en eventos de fallo.

A diferencia de Copy Fail, la nueva técnica elude la principal medida de protección temporal conocida: el bloqueo del módulo algif_aead. Esto convierte en incompletos todos los «quick fixes» actuales para Copy Fail: la infraestructura que se basó únicamente en la lista de bloqueo para algif_aead obtiene una falsa sensación de seguridad mientras se mantiene intacto el riesgo completo de compromiso local de root.

Evaluación del impacto en las organizaciones

Corren mayor riesgo los entornos donde un posible atacante puede obtener cualquier tipo de acceso local, ya sea interactivo directo o mediante la explotación de otras vulnerabilidades de aplicaciones:

• proveedores de servicios cloud y de hosting con servidores Linux multiusuario;
• servidores corporativos de aplicaciones (web, bases de datos, CI/CD), donde la compromisión de un servicio proporciona acceso local de bajo nivel;
• escritorios virtuales y servidores de terminal sobre Linux con multitud de cuentas no privilegiadas;
• entornos de desarrollo y pruebas, donde a menudo se habilitan subsistemas adicionales del kernel y existen políticas de seguridad menos estrictas.

Posibles consecuencias si no se actúa:

• elevación instantánea de privilegios a root tras cualquier foothold local (RCE en una aplicación web, cuenta de usuario comprometida, contenedor vulnerable);
• persistencia en el sistema mediante la modificación de binarios de sistema, bootloaders, módulos del kernel o configuraciones;
• desactivación o sustitución de los medios de protección (agentes EDR, registros de auditoría);
• incumplimiento de requisitos de conformidad en los que el control de acceso administrativo y la integridad del sistema son elementos clave de auditoría.

El peligro particular reside en que, según el investigador, ya existe un PoC plenamente funcional que realiza la escalada «con un solo comando». Esto reduce drásticamente el tiempo entre la aparición de la vulnerabilidad y su inclusión masiva en conjuntos de exploits, incluidos los automatizados.

Recomendaciones prácticas de protección

1. Medidas temporales inmediatas

Hasta que se publiquen los parches oficiales del kernel Linux se recomienda:

• bloquear la carga de los módulos esp4, esp6 y rxrpc:
  • añadir en los ficheros de /etc/modprobe.d/ las líneas:
    • blacklist esp4
    • blacklist esp6
    • blacklist rxrpc
  • si es posible, descargar los módulos ya cargados: rmmod esp4 esp6 rxrpc (teniendo en cuenta los riesgos de interrupción de servicios).
• evaluar de forma consciente el impacto en la infraestructura: el bloqueo de esp4/esp6 afectará a túneles IPSec, y la desactivación de rxrpc impactará a los servicios que utilicen este protocolo.

Esto se correlaciona directamente con la recomendación del proveedor AlmaLinux, que describe el defecto en la ruta «ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path» y su explotabilidad a través de la interfaz XFRM user netlink.

2. Verificación de la exposición

Pasos básicos para evaluar el riesgo:

• Determinar las distribuciones y versiones dentro del área de riesgo:
  • confirmadas de base: Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44;
  • si se utilizan versiones de kernel similares, otras distribuciones también pueden ser vulnerables.
• Comprobar si los módulos correspondientes están cargados:
  • lsmod | egrep 'esp4|esp6|rxrpc'
  • si es necesario, modinfo esp4, modinfo rxrpc para confirmar la presencia de los módulos en el sistema.
• Precisar las políticas de creación de user namespaces:
  • en sistemas Ubuntu, revisar los perfiles de AppArmor;
  • en servidores de otras distribuciones, limitar en lo posible la creación de user namespaces por parte de usuarios no privilegiados.

3. Refuerzo del monitoreo y los procedimientos de respuesta

Dado que existe un PoC, tiene sentido:

• monitorizar cargas inesperadas de los módulos esp4, esp6 y rxrpc (mediante auditd, systemd-journald y herramientas de monitoreo del kernel);
• controlar la ejecución de herramientas que utilizan splice() y sendfile() en combinaciones atípicas para el sistema, especialmente desde cuentas no privilegiadas;
• reforzar la respuesta ante cualquier señal de compromiso local —desde indicios de web shells hasta binarios sospechosos en el directorio personal de un usuario—: en presencia de Dirty Frag, cualquier acceso local debe considerarse como potencial obtención de root.

4. Preparación para la instalación de parches

Dado que los desarrolladores del kernel fueron notificados de la vulnerabilidad el 30 de abril de 2026, se esperan próximamente actualizaciones en las ramas mantenidas por las distribuciones. Se recomienda con antelación:

• planificar una actualización extraordinaria del kernel con posibles reinicios de nodos clave;
• preparar un entorno de pruebas para verificar el impacto de los parches en los servicios críticos (especialmente los que utilizan IPSec y RxRPC);
• seguir la publicación de la entrada para Copy Fail CVE-2026-31431 y vulnerabilidades relacionadas de la misma clase en la NVD, así como las recomendaciones de los proveedores de distribuciones.

Conclusión principal: Dirty Frag abre una vía universal hacia root para cualquier atacante local en la mayoría de las distribuciones Linux modernas, y las medidas temporales aplicadas previamente contra Copy Fail ya no proporcionan una protección suficiente; priorice el bloqueo inmediato de los módulos esp4, esp6 y rxrpc siempre que los procesos de negocio lo permitan, y prepare la infraestructura para desplegar rápidamente kernels actualizados en cuanto se publiquen los parches oficiales.