Dirty Frag é o Copyfail 2
Deja vu, eu já estive nesse lugar antes. Sejam bem vindos a segunda feira da escalação de privilégios. Sim, hoje vamos falar de novo sobre uma vulnerabilidade que permite um usuário comum adquirir permissões de administrador no Linux. Estou cansado chefe
Veja no canal:
- Pra quem não viu, nós fizemos um vídeo semana passada falando sobre o Copyfail. Esse exploit misturava a escrita do kernel em algumas páginas de memória e uma API de criptografia. Um erro de lógica permitia a corrupção de páginas de cache na memória e a criação de uma versão do su que elevava o usuário a administrador sem pedir a senha.
- “sir, a second exploit has hit the kernel”
-
O Dirty Frag na realidade é 2 outras vulnerabilidades que derivam do mesmo erro lógico só que em outros módulos do kernel. Um deles no esp4 e esp6 e outro no rxrpc
-
A existência desse exploit foi revelada 07/05/26. Com 0 patches prontos, foi lançado no seco… por quê? Nós já vamos falar, mas primeiro a explicação e mitigação.
-
Discussão no reddit /r/sysadmin
https://www.reddit.com/r/sysadmin/comments/1t6ocb8/dirty_frag_new_root_exploit_targeting_newest/
- Repositório oficial do exploit:
https://github.com/V4bel/dirtyfrag/
RedHat: https://access.redhat.com/security/vulnerabilities/RHSB-2026-003
Amazon Linux: https://aws.amazon.com/pt/security/security-bulletins/rss/2026-027-aws/
Ubuntu: https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available
Fedora: https://bodhi.fedoraproject.org/updates/FEDORA-2026-8cffa03dad
Alma Linux: https://almalinux.org/blog/2026-05-07-dirty-frag/
Explicação simples:
- É de novo um uso do método splice para juntar duas páginas na memória. O Copyfail usava isso para juntar uma página de criptografia que o módulo algif_aedusava com pagínas na memória que se queria corromper. Esse novo exploit vai na mesma linhas, mas usando os móduilos esp4, esp6 e rxrpc
Como mitigar:
- Dependendo de quando você ver esse vídeo talvez já tenha uma versão atualizada do kernel Linux para a sua distribuição, mas para mitigar é possível desabilitar os módulos como da outra vez.
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"
Em mais linhas:
echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null;
echo 3 > /proc/sys/vm/drop_caches; true"
- Desabilitar isso aqui vai fazer algumas funcionalidades do kernel não funcionarem. Eu tentei procurar pra vocês o que seria. Da postagem do Ubuntu:
Mitigation regression risk
The mitigations disable the kernel modules that are used for IPsec ESP and RxRPC, respectively. The mitigations will affect functionality if these are in use by either:
- IPsec deployments. These are common with VPN implementations such as StrongSwan.
- AFS (Andrew File System) or another application of RxRPC.
As the vulnerabilities are independent, disabling only the esp4/esp6 modules or only the rxrpc modules would leave the remaining ones exploitable.
Por que foi revelado assim no susto?
Timeline of disclosure:
- 2026-04-30: Submitted detailed information about the esp vulnerability and a weaponized exploit that achieves root privileges on several major distributions to security@kernel.org.
- 2026-04-30: Submitted the patch for the esp vulnerability to the netdev mailing list. Information about this issue was published publicly.
- 2026-04-30 (+9h): Kuan-Ting Chen submitted a vulnerability report for the esp vulnerability with a reproducer to security@kernel.org.
- 2026-05-04: Kuan-Ting Chen submitted the shared-frag approach patch to the netdev mailing list.
- 2026-05-07: The patch was merged into the netdev tree.
- 2026-05-07: Submitted detailed information about the vulnerability and the exploit to the linux-distros mailing list. The embargo was set to 5 days, with an agreement that if a third party publishes the exploit on the internet during the embargo period, the Dirty Frag exploit would be published publicly.
- 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
- 2026-05-07: After obtaining agreement from distribution maintainers to fully disclose Dirty Frag, the entire Dirty Frag document was published.
https://afflicted.sh/blog/posts/copy-fail-2.html
- Sim, isso mostra mais uma vez como a disponibilidade de LLMs bons o suficientes está criando situações perigosas.
- Hoje dá pra ter tempo hábil de ficar monitorando todos commits no Linux e descobrir que uma dessas pequenas mudanças era uma correção de vulnerabilidade que está no período de embargo.
- Nesse momento se esse texto tivesse sido escrito por um LLM eu ia dizer: “e isso muda o jogo” ou “e aqui está o pulo do gato”
- O que eu vou dizer é que não é só as agências de inteligência que podem fazer isso agora e isso tem suas partes boas e ruins.
Por que esse exploit é tão perigoso agora [2]
-
Essa parte é reciclada do vídeo do copyfail, mas é importante lembrar
-
A maneira que ele é explorado é rápida, portável e a junção dos 2 exploits consegue explorar basicamente todas as distros mais populares.
-
Poderia estar sendo explorado por aí de uma maneira silenciosa.
-
Não é um exploit com RCE (remote code execution), mas vai ser incluído nas ferramentas de invasão como um segundo passo após conseguir um shell numa máquina.
- Fora isso, alguém com acesso local à sua máquina conseguiria root sem senha.
- Hoje esse tipo de vulnerabilidade, junto com ferramentas de CI, VPS, malwares distribuídos pela cadeia de suprimentos se torna bem mais desastroso e é por isso que administradores de sistemas passaram mais um final de semana arrancando os cabelos 🙂
https://github.com/V4bel/dirtyfrag/issues/28/
Boa semana para todos e que o Linus tenha piedade da nossa nação