Dirty Frag encadena dos bugs de kernel en un root shell determinístico a partir de cualquier contenedor sin privilegios. En Tech86 vimos repetirse esta clase de vulnerabilidad, pero esta vez el objetivo más crítico está claro: los nodos de inferencia de IA con acceso a GPU. Un contenedor comprometido pivota a host root y compromete todos los workloads co-residentes. El aislamiento de contenedores protege contra el acceso indebido a recursos, no contra la corrupción de memoria compartida en el kernel.
El mecanismo: dos CVE, un encadenamiento, root determinístico
Dirty Frag explota el page cache del kernel, la caché compartida de páginas de archivo en memoria. Todos los procesos del host, incluidos los contenedores, referencian las mismas páginas cacheadas. No existe copia por namespace. No existe aislamiento por cgroup. El page cache es del host, y todos los procesos lo ven.
El CVE-2026-43284 (CVSS 8.8) ataca el subsistema xfrm-ESP del IPsec. Un bug de decryption in-place presente desde 2017 permite la escritura arbitraria de 4 bytes en el page cache vía spliced pipe. El CVE-2026-43500 (CVSS 7.8) ataca el subsistema RxRPC, con un bug introducido en 2023, la misma clase de primitiva de escritura. Encadenados, el atacante corrompe las páginas cacheadas de /usr/bin/su con el shellcode setuid(0) + execve("/bin/sh"), ejecuta su y obtiene un root shell. Determinístico. Sin race condition. Sin kernel panic. Un comando.
Probado y confirmado en Ubuntu 24.04, RHEL 10.1, Fedora 44, openSUSE, CentOS Stream 10 y AlmaLinux 10. Toda distribución Linux principal es vulnerable. Lo que diferencia a Dirty Frag de exploits anteriores como Dirty Pipe es la confiabilidad: no hay ventana de timing, no hay condición de carrera. El encadenamiento funciona siempre.
Por qué los nodos de IA son el objetivo de mayor valor
Los GPU compute nodes son hosts grandes que ejecutan decenas de contenedores simultáneamente. Un solo contenedor comprometido pivota a host root y afecta a todos los workloads co-residentes: modelos de inferencia, pipelines de datos, servicios de API. El blast radius es desproporcionado.
Los contenedores de IA frecuentemente ejecutan con privilegios elevados para el acceso CUDA. Esto reduce la barrera entre el contenedor y el host. Los workloads de entrenamiento en InfiniBand/RoCE con IPsec en kernel mode usan exactamente las interfaces de las que Dirty Frag abusa: AF_KEY y XFRM netlink son parte del stack de red de estos workloads. El atacante no necesita acceso privilegiado inicial: el propio workload legítimo carga los módulos vulnerables.
Los GPU pools multi-tenant de Kubernetes son el escenario más crítico. Nebius AI Cloud emitió un advisory explícito sobre container escape vía Dirty Frag. El page cache no respeta los límites de namespace: la corrupción dentro de un contenedor es visible para todos los procesos del host por diseño. En Tech86 consideramos esta dinámica al diseñar el aislamiento para workloads de IA: los contenedores no son boundaries de seguridad cuando el kernel comparte memoria.
9 años de ventana de exposición
El bug en xfrm-ESP fue introducido en 2017. Siete años después, en 2023, el bug en RxRPC amplió la superficie de ataque. En mayo de 2026, los parches se commitearon al mainline. El 7 de mayo, el embargo fue roto por Hyunwoo Kim (@v4bel). El 8 de mayo, Microsoft confirmó explotación activa in the wild.
Nueve años. Cualquier actor, estado-nación, grupo APT, operador de ransomware, que descubriera el bug en xfrm-ESP antes de mayo de 2026 tuvo una LPE indetectable contra todo el ecosistema Linux. Sin PoC público, sin advisory, sin parche. La detección de page cache corruption es notoriamente difícil. No hay firma de red, no hay log de syscall sospechoso. El exploit escribe en memoria compartida que el kernel considera válida.
En Tech86 aprendimos que las ventanas de exposición largas son la regla, no la excepción. El bug estuvo ahí durante casi una década. La pregunta no es si alguien explotó antes de la disclosure, sino cuántos explotaron sin que nadie lo supiera.
Lo que el default no protege
El perfil seccomp default de Docker bloquea AF_RXRPC. Pero NO bloquea AF_KEY. El perfil default de containerd tiene la misma laguna. Esto significa que la mayoría de los clústeres Kubernetes en producción permite la syscall que el CVE-2026-43284 usa para iniciar el encadenamiento.
Pod Security Standards en el perfil Restricted con allowPrivilegeEscalation: false bloquea la etapa final, la escalada de privilegios que convierte la corrupción del page cache en ejecución de código. Pero no impide la corrupción en sí. El page cache ya está corrompido: el atacante solo necesita encontrar otro camino para escalar. Es una capa necesaria, no suficiente.
La blacklist de módulos en /etc/modprobe.d/dirtyfrag.conf, install esp4 /bin/false, install esp6 /bin/false, install rxrpc /bin/false, elimina los vectores sin reboot. Pero el tradeoff es real: deshabilitar esp4/esp6 termina los túneles IPsec en kernel mode. Para workloads que dependen de IPsec, esta mitigación no es viable sin reestructurar el stack de red.
La corrección real es arquitectural
Los parches son necesarios y urgentes. Kernel 6.18.22+, 6.19.12+ o 7.0+ incluyen las correcciones. AWS, Azure y GKE ya desplegaron node images corregidas. Pero los parches son reactivos: corrigen el bug específico, no la clase de vulnerabilidad.
El kernel Linux no fue diseñado con el aislamiento del page cache entre contenedores en mente. Cada subsistema que interactúa con el page cache es una potencial superficie de ataque. Dirty Pipe (2022), CopyFail (CVE-2026-31431) y Dirty Frag son todos de la misma clase. El patrón es claro. Mientras los contenedores compartan el mismo kernel y el mismo page cache, esta vulnerabilidad seguirá apareciendo.
Para GPU nodes multi-tenant, la defensa real es el aislamiento de kernel: gVisor, Kata Containers o nodos dedicados. En Tech86 operamos Kubernetes con seccomp personalizado por workload, Pod Security Standards Restricted como estándar y nodos con kernel actualizado en horas. Para workloads de IA que exigen aislamiento real, ofrecemos ambientes con kernel dedicado, porque la experiencia nos mostró que los contenedores solos no son suficientes cuando el atacante tiene una primitiva de escrita en el page cache.
Si tu clúster Kubernetes ejecuta workloads de IA en GPU nodes multi-tenant, Dirty Frag es la pesadilla que tu threat model necesita incluir. Conoce nuestra Cloud Gerenciada y entiende cómo operamos infraestructura con las capas de seguridad que esta realidad exige.