Dirty Frag encadeia dois bugs de kernel em um root shell determinístico a partir de qualquer container sem privilégio. Na Tech86, vimos essa classe de vulnerabilidade se repetir — mas desta vez, o alvo mais crítico está claro: nodes de inferência AI com acesso GPU. Um container comprometido pivota para host root e compromete todos os workloads co-residentes. Container isolation protege contra acesso indevido a recursos, não contra corrupção de memória compartilhada no kernel.
O mecanismo: dois CVEs, um encadeamento, root determinístico
Dirty Frag explora o page cache do kernel — o cache compartilhado de páginas de arquivo em memória. Todos os processos no host, incluindo containers, referenciam as mesmas páginas cacheadas. Não existe cópia por namespace. Não existe isolamento por cgroup. O page cache é do host, e todos os processos o enxergam.
O CVE-2026-43284 (CVSS 8.8) ataca o subsistema xfrm-ESP do IPsec. Um bug de decryption in-place presente desde 2017 permite escrita arbitrária de 4 bytes no page cache via spliced pipe. O CVE-2026-43500 (CVSS 7.8) ataca o subsistema RxRPC, com bug introduzido em 2023 — mesma classe de write primitive. Encadeados, o atacante corrompe as páginas cacheadas de /usr/bin/su com shellcode setuid(0) + execve("/bin/sh"), executa su e obtém root shell. Determinístico. Sem race condition. Sem kernel panic. Um comando.
Testado e confirmado em Ubuntu 24.04, RHEL 10.1, Fedora 44, openSUSE, CentOS Stream 10 e AlmaLinux 10. Toda distribuição Linux major é vulnerável. O que diferencia Dirty Frag de exploits anteriores como Dirty Pipe é a confiabilidade: não há janela de timing, não há condição de corrida. O encadeamento funciona sempre.
Por que nodes de IA são o alvo de maior valor
GPU compute nodes são hosts grandes rodando dezenas de containers simultaneamente. Um único container comprometido pivota para host root e afeta todos os workloads co-residentes — modelos de inferência, pipelines de dados, serviços de API. O blast radius é desproporcional.
Containers de AI frequentemente rodam com privilégios elevados para acesso CUDA. Isso reduz a barreira entre o container e o host. Workloads de treinamento em InfiniBand/RoCE com IPsec em kernel mode usam exatamente as interfaces que Dirty Frag abusa — AF_KEY e XFRM netlink são parte do stack de rede desses workloads. O atacante não precisa de acesso privilegiado inicial; o próprio workload legítimo carrega os módulos vulneráveis.
Kubernetes multi-tenant GPU pools são o cenário mais crítico. A Nebius AI Cloud emitiu advisory explícito sobre container escape via Dirty Frag. O page cache não respeita namespace boundaries — corrupção dentro de um container é visível para todos os processos no host por design. Na Tech86, consideramos essa dinâmica ao desenhar isolamento para workloads de IA: containers não são boundaries de segurança quando o kernel compartilha memória.
9 anos de janela de exposição
O bug no xfrm-ESP foi introduzido em 2017. Sete anos depois, em 2023, o bug no RxRPC ampliou a superfície de ataque. Em maio de 2026, os patches foram commitados no mainline. Em 7 de maio, o embargo foi quebrado por Hyunwoo Kim (@v4bel). Em 8 de maio, a Microsoft confirmou exploração ativa no wild.
Nove anos. Qualquer ator — estado-nação, grupo APT, operador de ransomware — que descobriu o bug no xfrm-ESP antes de maio de 2026 teve LPE indetectável contra todo o ecossistema Linux. Sem PoC público, sem advisory, sem patch. A detecção de page cache corruption é notoriamente difícil. Não há assinatura de rede, não há log de syscall suspeito. O exploit escreve em memória compartilhada que o kernel considera válida.
Na Tech86, aprendemos que janelas de exposição longas são a regra, não a exceção. O bug estava lá por quase uma década. A questão não é se alguém explorou antes da disclosure — é quantos exploraram sem que ninguém soubesse.
O que o default não protege
O seccomp profile default do Docker bloqueia AF_RXRPC. Mas NÃO bloqueia AF_KEY. O perfil default do containerd tem a mesma lacuna. Isso significa que a maioria dos clusters Kubernetes em produção permite a syscall que o CVE-2026-43284 usa para iniciar o encadeamento.
Pod Security Standards no perfil Restricted com allowPrivilegeEscalation: false bloqueia a etapa final — a escalada de privilégio que transforma corrupção de page cache em execução de código. Mas não impede a corrupção em si. O page cache já está corrompido; o atacante só precisa encontrar outro caminho para escalar. É uma camada necessária, não suficiente.
A blacklist de módulos em /etc/modprobe.d/dirtyfrag.conf — install esp4 /bin/false, install esp6 /bin/false, install rxrpc /bin/false — remove os vetores sem reboot. Mas o tradeoff é real: desabilitar esp4/esp6 termina túneis IPsec em kernel mode. Para workloads que dependem de IPsec, essa mitigação não é viável sem reestruturar o stack de rede.
A correção real é arquitetural
Patches são necessários e urgentes. Kernel 6.18.22+, 6.19.12+ ou 7.0+ incluem as correções. AWS, Azure e GKE já rollaram node images corrigidas. Mas patches são reativos — corrigem o bug específico, não a classe de vulnerabilidade.
O kernel Linux não foi projetado com isolamento de page cache entre containers em mente. Cada subsistema que interage com o page cache é uma potencial superfície de ataque. Dirty Pipe (2022), CopyFail (CVE-2026-31431) e Dirty Frag são todos da mesma classe. O padrão é claro. Enquanto containers compartilharem o mesmo kernel e o mesmo page cache, essa vulnerabilidade vai continuar aparecendo.
Para GPU nodes multi-tenant, a defesa real é isolamento de kernel: gVisor, Kata Containers ou nodes dedicados. Na Tech86, operamos Kubernetes com seccomp customizado por workload, Pod Security Standards Restricted como padrão e nodes com kernel atualizado em horas. Para workloads de IA que exigem isolamento real, oferecemos ambientes com kernel dedicado — porque a experiência nos mostrou que containers sozinhos não são suficientes quando o atacante tem um write primitive no page cache.
Se o seu cluster Kubernetes roda workloads de IA em GPU nodes multi-tenant, Dirty Frag é o pesadelo que seu threat model precisa incluir. Conheça nossa Cloud Gerenciada e entenda como operamos infraestrutura com as camadas de segurança que essa realidade exige.