Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Procurando medidas de mitigação? Pule para a seção a seguir ↓
A versão resumida
- O que: Uma cadeia de escalonamento de privilégios local no Linux chamada Dirty Frag, que combina CVE-2026-43284 (gravação no cache de páginas do xfrm-ESP) e CVE-2026-43500 (gravação no cache de páginas do RxRPC).
- Impacto: Explorações públicas de prova de conceito demonstram uma escalada confiável de privilégios de root a partir de uma conta local sem privilégios em kernels vulneráveis.
- Status: Estão circulando exploits públicos que funcionam. O embargo foi quebrado antes que a aplicação coordenada de correções fosse concluída.
- Gravidade: Vetor de ataque local, baixa complexidade, sem interação do usuário, exploração determinística. CVSS: 7,8 (provisório)
- Faça isso agora:protejaos kernels afetados imediatamente. A aplicação de patches sem reinicialização mitiga a vulnerabilidade “Dirty Frag” sem a necessidade de aguardar janelas de manutenção ou reinicializações. Caso contrário, implante os kernels corrigidos o mais rápido possível. Se nenhuma dessas opções estiver disponível imediatamente, desative temporariamente os caminhos vulneráveis ESP e RxRPC descritos abaixo.
Isso me afeta?
É provável que você seja afetado se estiver executando um kernel recente derivado da linha principal em qualquer um dos seguintes sistemas:
- Ubuntu (versões LTS e atuais)
- Red Hat Enterprise Linux, AlmaLinux, Rocky Linux, CentOS Stream
- Fedora
- openSUSE Tumbleweed
- A maioria das compilações derivadas, incluindo as variantes do CloudLinux
Verificação rápida dos módulos expostos:
lsmod | grep -E '^(esp4|esp6|rxrpc) '
Se algum desses arquivos estiver carregado — ou puder ser carregado automaticamente sob demanda por um usuário sem privilégios —, você deve considerar o host como vulnerável até que seja aplicado o patch.
Você está não automaticamente seguro só porque se inscreveu antes Falha na cópia . Bloqueie algif_aead não impede o Dirty Frag.
O que é o “Dirty Frag”
O Dirty Frag é uma cadeia de escalonamento de privilégios local (LPE) no kernel que explora duas rotas de descriptografia no próprio local na pilha de rede do Linux:
- xfrm-ESP (esp4, esp6), utilizado pelo IPsec
- RxRPC (rxrpc), utilizado pelo AFS e pelo tráfego RPC relacionado
Ele pertence à mesma família de bugs que o Dirty Pipe e o Copy Fail: uma rotina do kernel grava dados em uma página da qual não é proprietária exclusiva, acabando por sobrescrever o conteúdo de uma entrada do cache de páginas que corresponde a um arquivo no disco.
A cadeia foi divulgada pelo pesquisador Hyunwoo Kim. ‘Copy Fail 2: Electric Boogaloo’ é a parte xfrm-ESP do Dirty Frag (CVE-2026-43284), obtida por engenharia reversa a partir do commit público da correção – não se trata de um CVE separado nem da cadeia completa.
Como a vulnerabilidade realmente funciona
O cache de páginas do Linux mantém cópias do conteúdo dos arquivos na memória, de modo que leituras repetidas não precisem acessar o disco. Quando você executa o comando `cat /etc/passwd`, o kernel quase sempre fornece os bytes a partir de uma página em cache, em vez de buscá-los no sistema de arquivos. Essa página em cache é compartilhada: todos que acessam esse arquivo veem a mesma memória.
Suporte às rotas de recepção modernas do kernel descriptografia sem cópia . Quando dados de rede criptografados chegam — por exemplo, um pacote IPsec encapsulado em ESP —, o kernel pode descriptografá-los diretamente em uma página de destino, em vez de alocar um novo buffer e copiá-los duas vezes. Esse processo é rápido e, para a maioria dos destinos, é seguro, pois a página de destino é algo que o kernel alocou para essa finalidade.
O “Dirty Frag” ocorre quando a página de destino é não de propriedade privada. Por meio de chamadas cuidadosamente construídas splice(2) ou sendfile(2) , um processo sem privilégios pode fazer com que o ESP do kernel ou o caminho de recepção RxRPC descriptografe os dados recebidos diretamente em uma página que esteja atualmente servindo ao cache de páginas — incluindo páginas que armazenam arquivos confidenciais, como /etc/passwd ou /usr/bin/su.
Os bytes descriptografados estão sob o controle do invasor (o invasor escolheu o texto em claro antes de criptografá-lo e enviá-lo). Como o kernel não utiliza COW nem isola de outra forma a página de destino, a gravação ocorre na cópia compartilhada do cache de páginas. As leituras subsequentes do arquivo — incluindo as realizadas por login, sudo ou su – retornam o conteúdo modificado.
O arquivo no disco permanece inalterado. No entanto, leituras posteriores podem utilizar a versão modificada armazenada em cache, em vez do conteúdo original do sistema de arquivos.
Dois caminhos são encadeados para garantir a cobertura da distribuição:
- O caminho do ESP requer a criação de um namespace de usuário sem privilégios, o que o Ubuntu bloqueia por meio do AppArmor, mas a maioria das outras distribuições permite.
- O caminho do RxRPC requer que o módulo rxrpc.ko esteja carregado, o que a maioria das distribuições não inclui por padrão – mas o Ubuntu inclui. O bloqueio de namespace do Ubuntu é contornado pelo RxRPC; para todas as outras distribuições, a falta do rxrpc é contornada pelo ESP.
Juntas, elas abrangem as configurações de fortalecimento mais comuns.
O que torna essa falha excepcionalmente perigosa na prática:
- Determinístico: Sem janela de corrida, sem primitivas sensíveis ao tempo.
- Silêncio em caso de falha: Tentativas malsucedidas normalmente não causam pânico no kernel.
- Alta taxa de sucesso: Confiável o suficiente para que o PoC público funcione logo na primeira tentativa.
- Militarização rápida: Cadeias de exploração públicas surgiram antes que a aplicação coordenada de patches fosse concluída, reduzindo drasticamente o tempo de resposta dos defensores.
Mitigação
A medida de correção mais segura é proteger imediatamente o kernel em execução. Existem três maneiras práticas de reduzir a exposição, listadas aqui em ordem de rapidez e impacto operacional.
1. Aplicação de patches sem reinicialização (mais rápida, sem tempo de inatividade)
Os patches sem reinicialização do KernelCare estão sendo implementados para as famílias de kernels corporativos afetadas, permitindo que os kernels vulneráveis em execução sejam protegidos sem a necessidade de aguardar janelas de manutenção de emergência ou reinicializações coordenadas.
Para organizações que operam infraestruturas em que o tempo de atividade é fundamental, isso reduz imediatamente o tempo de correção, enquanto as atualizações padrão do kernel dos fornecedores e os ciclos de reinicialização se atualizam.
À medida que novas versões dos pacotes do kernel a jusante forem lançadas, a detecção pelo scanner e os relatórios de versão do fornecedor podem ficar temporariamente desatualizados em relação ao estado do kernel em execução protegido.
| Ainda não é cliente da KernelCare? Os preços para novos clientes têm desconto até o final de junho. Saiba mais sobre a KernelCare aqui. |
2. Instale um kernel corrigido e reinicie o sistema
O procedimento padrão de correção consiste em implantar os pacotes de kernel corrigidos fornecidos pelo fornecedor e reiniciar os sistemas afetados assim que for operacionalmente possível.
Priorize os sistemas nos quais código parcialmente confiável pode ser executado – incluindo nós do Kubernetes, executores de CI/CD, ambientes de hospedagem compartilhada, infraestrutura de desenvolvedores e cargas de trabalho multilocatárias.
3. Mitigação manual temporária (caso a aplicação do patch tenha que ser adiada)
Caso não haja disponibilidade de correções sem reinicialização nem de janelas de reinicialização imediata, os caminhos ESP e RxRPC vulneráveis podem ser temporariamente desativados por meio do bloqueio de módulos.
Leia isto primeiro
Bloquear o esp4 e o esp6 prejudicará o funcionamento do IPsec. Se você estiver terminando ou roteando tráfego IPsec — strongSwan, Libreswan, VPNs site a site ou clientes “road-warrior” —, aplicar essa configuração em servidores de produção fará com que esses túneis sejam interrompidos.
Antes de realizar uma implantação em larga escala, verifique se os módulos não estão em uso ativo.
ip xfrm policy list 2>/dev/null | head
ss -tunap | grep -i rxrpc
Se a saída não estiver vazia, avalie o impacto antes de prosseguir.
Bloqueie os módulos vulneráveis
sudo 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; true"
Se houver suspeita de comprometimento
Limpe o cache de páginas para que quaisquer arquivos binários em cache que tenham sido modificados sejam removidos e relidos do disco no próximo acesso:
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
Considere isso como uma etapa forense, não como uma solução. Se um invasor já tiver obtido privilégios de root por meio do Dirty Frag, a remoção do cache de páginas não elimina nada do que ele tenha feito após a escalada de privilégios.
Detecção
Atualmente, não existe nenhum método de detecção pós-hoc amplamente aceito ou confiável para confirmar o sucesso da exploração do Dirty Frag. Os arquivos no disco permanecem intactos, e o ataque não deixa nenhum padrão de chamada de sistema tão característico quanto o do Dirty Pipe. Dito isso, vale a pena procurar por alguns sinais:
- Carregamento inesperado de esp4, esp6ou rxrpc em hosts que não têm nada a ver com IPsec ou AFS. Regra do auditd:
-w /sbin/modprobe -p x -k module_load
- Criação de novos espaços de nome de rede por usuários sem privilégios em sistemas nos quais isso não faz parte da carga de trabalho normal. Rastreie por meio de unshare ou eBPF.
- Execução com setuid por contas que nunca tenham chamado anteriormente su ou sudo, especialmente logo após atividades intensas envolvendo splice/sendfile.
- Clientes do Imunify360: indicadores relacionados ao script de implantação do PoC público foram adicionados à lista de bloqueio.
Trata-se de diretrizes, não de garantias. Considere que qualquer host no qual um usuário local não confiável tenha tido acesso ao shell durante o período de exposição está potencialmente comprometido.
Lista de verificação de medidas corretivas priorizadas
- Correção: Aplique um patch que não exija reinicialização ou implante um kernel corrigido imediatamente. Os usuários do KernelCare podem proteger os kernels em execução compatíveis sem precisar reiniciar, enquanto as janelas de manutenção padrão são atualizadas. Caso contrário, instale kernels corrigidos pelo fornecedor e reinicie os sistemas afetados o mais rápido possível.
- Se você não puder aplicar a correção imediatamente, aplique a medida de mitigação de bloqueio de módulos descrita acima – após confirmar que você não depende do IPsec ou do RxRPC.
- Auditar o acesso local: Verifique quem atualmente possui acesso ao shell em hosts compartilhados, executores de CI/CD, servidores de compilação e sistemas multilocatários. Revogue os acessos que não forem necessários durante esse período.
- Pesquisar: Execute as consultas de detecção acima na janela de exposição.
- Reinicie após a aplicação do patch: Isso limpará todas as páginas em cache que possam ter sido modificadas, juntamente com o kernel antigo.
Por que bugs como o “Dirty Frag” estão surgindo mais rapidamente
O Dirty Frag também reflete uma tendência mais ampla do setor: a auditoria assistida por IA está acelerando a descoberta de falhas profundas e de longa duração em caminhos de código críticos para o desempenho.
Em uma publicação recente, Igor Seletskiy, CEO da TuxCare, argumentou que a análise moderna assistida por IA está reduzindo drasticamente o tempo necessário para identificar vulnerabilidades sutis no kernel e na infraestrutura que, anteriormente, passavam despercebidas mesmo após anos de análise.
O Dirty Frag se encaixa perfeitamente nesse padrão: uma falha de propriedade do cache de páginas oculta em caminhos de rede de alto desempenho, agora transformada em um meio confiável de escalonamento de privilégios, com código de exploração já disponível publicamente.
Referências
CVE-2026-43284 (Gravação no cache de página do xfrm-ESP) — Entrada no NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-43284
CVE-2026-43500 (Gravação no cache de páginas do RxRPC) — Entrada no NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-43500
- Observação: a entrada RxRPC está reservada para acompanhamento, enquanto a entrada NVD aguarda publicação; portanto, a página pode aparecer como “RESERVADA” até que seja preenchida.
Relato original do pesquisador — Hyunwoo Kim (@v4bel):
- Site hospedado: https://dirtyfrag.io
- Artigo técnico completo no GitHub: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md
- Repositório do PoC / README: https://github.com/V4bel/dirtyfrag
- E-mail de divulgação de vulnerabilidade da OSS-Security (7 de maio de 2026): https://www.openwall.com/lists/oss-security/2026/05/07/8
Série de patches do kernel upstream (lore.kernel.org):
- Tópico sobre o patch do RxRPC (mencionado no comunicado do AlmaLinux): https://lore.kernel.org/all/afKV2zGR6rrelPC7@v4bel/
- Para a correção ESP incorporada, a referência canônica do commit é a mainline f4c50a4034e6: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4
Aviso do AlmaLinux: https://almalinux.org/blog/2026-05-07-dirty-frag/
