Administradores de sistemas Linux tiveram pouco tempo para respirar depois do Copy Fail. Uma semana após aquela vulnerabilidade ser corrigida, o mesmo pesquisador que a descobriu divulgou uma segunda, mais abrangente e, no momento da publicação, sem correção disponível. O nome é Dirty Frag, a técnica é semelhante, o impacto é maior e o timing foi pior: o exploit chegou ao público antes que qualquer distribuição tivesse preparado um patch.
A situação se resume assim: existem exploits públicos funcionando em circulação. O embargo foi quebrado antes que o processo de correção coordenada fosse concluído. A gravidade é alta: vetor de ataque local, baixa complexidade, sem interação do usuário, exploração determinística.
Determinística é a palavra-chave aqui. A maioria dos exploits de kernel depende de condições de corrida, timing preciso ou manipulação cuidadosa da memória heap. O Dirty Frag não. Ele é uma falha lógica: quando executado, funciona. Quando falha, o kernel não entra em pânico. A taxa de sucesso é alta.
O Que é o Dirty Frag e Como Ele Funciona
O Dirty Frag é uma cadeia de vulnerabilidades que combina duas falhas distintas no kernel Linux para obter privilégios de root a partir de uma conta de usuário sem privilégios.
O Dirty Frag é uma classe de vulnerabilidade que obtém privilégios de root na maioria das distribuições Linux encadeando a vulnerabilidade xfrm-ESP Page-Cache Write e a vulnerabilidade RxRPC Page-Cache Write, segundo o pesquisador de segurança Hyunwoo Kim (@v4bel) em seu write-up. A vulnerabilidade xfrm-ESP Page-Cache Write foi introduzida num commit de código-fonte feito em janeiro de 2017, enquanto a vulnerabilidade RxRPC Page-Cache Write foi introduzida em junho de 2023.
Para entender o mecanismo, é necessário conhecer três conceitos. O page cache (cache de páginas) é uma área da memória RAM que o kernel Linux usa para armazenar temporariamente dados lidos de discos, acelerando operações de entrada e saída. O xfrm-ESP é o subsistema do kernel responsável por gerenciar o protocolo ESP (Encapsulating Security Payload, ou Carga Útil de Segurança Encapsulada), que é parte do IPSec, o conjunto de protocolos usado em VPNs e conexões seguras de rede. O RxRPC é um protocolo de transporte usado principalmente pelo AFS (Andrew File System), um sistema de arquivos distribuído.
A falha está no caminho de descriptografia em contexto, dos módulos esp4, esp6 e rxrpc. Quando o caminho de recepção descriptografa dados em buffers paginados que não são de propriedade exclusiva do kernel (por exemplo, páginas de pipe acessadas via splice ou sendfile), processos sem privilégios podem reter referências ao texto simples resultante, gerando uma primitiva de escrita no cache de páginas que o exploit público transforma em acesso root com um único comando.
Uma “primitiva de escrita no cache de páginas” é essencialmente a capacidade de modificar dados que o kernel considera seguros e imutáveis por processos sem privilégios. Quando um atacante consegue escrever arbitrariamente nessa memória, pode corromper arquivos de sistema, modificar binários privilegiados ou alterar dados de autenticação, abrindo caminho para o controle total da máquina.
Dois CVEs, Dois Caminhos de Exploração
A complexidade do Dirty Frag está em como ele contorna as proteções diferentes de cada distribuição usando a combinação das duas falhas.
O CVE-2026-43284 é uma vulnerabilidade de condição de escrita arbitrária no subsistema xfrm-ESP (IPSec) do kernel Linux que pode ser explorada desde 2017. Quando explorada, concede ao atacante a capacidade de escrever um valor arbitrário em um local arbitrário. O CVE-2026-43284 tem uma pontuação de severidade CVSS de 8.8. O CVE-2026-43500 é uma escrita fora dos limites no subsistema RxRPC do kernel Linux que pode ser explorada desde 2023. O CVE-2026-43500 tem uma pontuação de severidade CVSS de 7.8.
No CVSS (Common Vulnerability Scoring System, ou Sistema de Pontuação de Vulnerabilidades), a escala vai de 0 a 10. Uma pontuação de 8.8 é classificada como Alta. Uma de 7.8 também é Alta. As duas juntas, encadeadas, produzem um exploit que funciona em praticamente qualquer distribuição Linux moderna.
A vulnerabilidade xfrm-ESP Page-Cache Write, enraizada no subsistema IPSec (xfrm), fornece aos atacantes uma primitiva de armazenamento de 4 bytes e sobrescreve uma pequena quantidade no cache de páginas do kernel. No entanto, o exploit exige que o usuário sem privilégios crie um namespace, um passo que é bloqueado pelo Ubuntu através do AppArmor. Em tal ambiente, o xfrm-ESP Page-Cache Write não pode ser acionado. É aí que entra o segundo exploit, o RxRPC Page-Cache Write. O RxRPC Page-Cache Write não exige o privilégio de criar um namespace, mas o módulo rxrpc.ko em si não está incluído na maioria das distribuições.
Em distribuições sem AppArmor (como RHEL, Arch Linux, Fedora, CentOS Stream, AlmaLinux e OpenSUSE), o CVE-2026-43284 sozinho é suficiente para obter root. Em distribuições com AppArmor ativo, como Ubuntu 24 e Ubuntu 26, o pesquisador encadeou o CVE-2026-43500 (RxRPC) para contornar a proteção. O resultado é que o Dirty Frag funciona em ambos os cenários, usando caminhos diferentes.
Por que Não Havia Patches no Momento da Divulgação
O motivo pelo qual o Dirty Frag chegou ao público antes dos patches é especificamente a quebra de embargo, e não uma falha da equipe de segurança do kernel.
A divulgação se tornou pública em 8 de maio de 2026, após um terceiro quebrar o embargo coordenado, forçando Kim a divulgar o exploit completo antes que qualquer distribuição tivesse emitido um patch. O código do exploit do Dirtyfrag chegou a repositórios públicos como o GitHub antes que patches oficiais ou um identificador CVE fossem atribuídos. Os defensores estão agora correndo contra atacantes que têm código de exploit completamente funcional enquanto os patches ainda não existem.
A vulnerabilidade foi reportada aos mantenedores do kernel Linux em 30 de abril de 2026.
O processo padrão de divulgação coordenada funciona assim: o pesquisador reporta a vulnerabilidade em privado, a equipe de segurança prepara patches, as distribuições são notificadas com antecedência para preparar suas atualizações e, quando tudo está pronto, a divulgação pública acontece junto com os patches. Nesse caso, alguém com acesso ao embargo vazou as informações antes que esse processo fosse concluído, deixando todas as partes — pesquisador, equipe do kernel e distribuidores — sem outra opção a não ser divulgar publicamente o que sabiam.
A teoria mais provável, mencionada em múltiplas fontes, é que atacantes já haviam descoberto a vulnerabilidade de forma independente e estavam usando-a. A quebra do embargo teria sido motivada exatamente para forçar a divulgação e a criação dos patches antes que o uso malicioso se espalhasse ainda mais.
Status dos Patches: O que Está Disponível
A Linux Kernel Organization lançou patches, que estão vinculados no National Vulnerability Database (NVD), para corrigir o CVE-2026-43284 em 8 de maio de 2026. Clientes que ainda não aplicaram esses patches são instados a fazê-lo o mais rápido possível. Em 8 de maio de 2026, patches para o CVE-2026-43500 ainda não estavam disponíveis. O CVE-2026-43500 está registrado para o problema RxRPC, mas ainda não foi publicado no NVD.
O quadro em 22 de maio de 2026 é o seguinte. O patch do CVE-2026-43284 está disponível no mainline do kernel e a maioria das distribuições principais já o incorporou. Para o CVE-2026-43500, os patches estão em processo de preparação pelos mantenedores do kernel e pelas distribuições, com disponibilidade prevista para os próximos dias. O Ubuntu confirmou que correções para ambos os CVEs estão disponíveis para todas as versões com suporte ativo.
A Mitigação Imediata: Desativar os Módulos Vulneráveis
Enquanto os patches não são aplicados, a mitigação recomendada pelo próprio pesquisador e confirmada pela Canonical (responsável pelo Ubuntu), pela Red Hat e pela Microsoft é desativar os módulos de kernel vulneráveis.
O pesquisador Kim recomendou que as equipes de segurança desativem os módulos vulneráveis do kernel executando o seguinte script como mitigação temporária para o Dirty Frag: 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”
O que esse comando faz: ele cria um arquivo de configuração que instrui o kernel a se recusar a carregar os módulos esp4, esp6 e rxrpc no futuro, e tenta descarregá-los da memória se estiverem atualmente ativos. O redirecionamento de 2>/dev/null garante que erros de módulos não carregados sejam silenciados, e o ; true faz o script sempre retornar código de sucesso.
Antes de aplicar a mitigação, é necessário avaliar o impacto operacional: desativar esp4 e esp6 pode quebrar a funcionalidade IPSec, e desativar rxrpc pode impactar ambientes baseados em AFS.
Na prática, a grande maioria dos servidores Linux de uso geral não usa IPSec diretamente no servidor (VPNs IPSec costumam ser gerenciadas por dispositivos dedicados) e AFS é raro fora de ambientes acadêmicos e corporativos específicos. Para servidores web, de aplicação, de banco de dados e a maioria dos casos de uso comuns, essa mitigação tem impacto operacional mínimo ou nulo.
Para verificar se os módulos estão ativos antes de rodar o comando, use lsmod | grep -E 'esp4|esp6|rxrpc'. Sem saída significa que os módulos não estão carregados, e o risco já é menor.
Quais Sistemas São Afetados
As vulnerabilidades afetam múltiplas distribuições Linux, incluindo todas as versões do Ubuntu com suporte. O CVE-2026-43284 tem uma pontuação CVSS 3.1 de 8.8 (ALTA). O CVE-2026-43500, avaliado pela Canonical, tem pontuação CVSS 3.1 de 7.8, correspondendo também a severidade ALTA. Em hosts que não executam cargas de trabalho de contêiner, a vulnerabilidade permite que um usuário local eleve privilégios ao usuário root.
Sistemas menos vulneráveis incluem ambientes Kubernetes com perfis seccomp padrão, onde as restrições de namespaces limitam a superfície de ataque. A exploração é menos provável em ambientes de contêiner endurecidos, como Kubernetes com perfis seccomp padrão. No entanto, o risco permanece significativo para máquinas virtuais ou ambientes menos restritos.
A lista de distribuições confirmadas como afetadas inclui todas as versões do Ubuntu com suporte ativo (20.04, 22.04, 24.04, 26.04), RHEL 8 e 9, CentOS Stream, Fedora, Arch Linux, AlmaLinux, OpenSUSE e praticamente qualquer distribuição que use um kernel derivado do mainline do Linux a partir de 2017.
O Contexto: Dois Exploits de Root em Duas Semanas
O Dirty Frag não surgiu no vácuo. Ele é o segundo exploit grave de escalada de privilégios no kernel Linux em menos de duas semanas, descoberto pelo mesmo pesquisador.
Uma semana após o Copy Fail (CVE-2026-31431), o pesquisador Hyunwoo Kim divulgou um segundo escalonamento de privilégios local no kernel Linux na mesma área ampla, IPsec ESP e rxrpc, e o nomeou Dirty Frag. Um exploit público funcional existe; qualquer usuário local sem privilégios pode usá-lo para obter root com um único comando. Um segundo exploit público chamado Copy Fail 2: Electric Boogaloo se refere a esta mesma vulnerabilidade com um nome alternativo.
A proximidade temporal entre Copy Fail e Dirty Frag, ambos no mesmo subsistema de rede do kernel, levanta questões sobre quantas outras vulnerabilidades semelhantes podem existir na mesma área de código. O pesquisador claramente fez uma análise aprofundada do subsistema xfrm e encontrou dois problemas distintos onde outros não haviam olhado.
O que Fazer Agora
A ordem de prioridades para administradores de sistemas Linux é clara. Primeiro, aplicar a mitigação de desativação dos módulos se o sistema ainda não tem patches. Segundo, atualizar o kernel assim que os patches estiverem disponíveis para a distribuição em uso. Terceiro, verificar com o responsável pela distribuição (Canonical, Red Hat, Arch, SUSE) o status dos pacotes de kernel atualizados.
Para sistemas Ubuntu, o comando apt update && apt upgrade já deve trazer os kernels corrigidos para ambos os CVEs. Para RHEL e derivados, dnf update kernel é o caminho. Para Arch Linux, pacman -Syu atualizará o kernel assim que o patch estiver no repositório.
Recomenda-se patcheamento sem reinicialização para mitigar o Dirty Frag sem esperar janelas de manutenção ou reinicializações. Caso contrário, implante kernels corrigidos assim que possível. Se nenhuma das opções estiver imediatamente disponível, desative temporariamente os caminhos ESP e RxRPC vulneráveis.
A linha de fundo é simples: o exploit existe, está disponível publicamente e funciona. Qualquer servidor Linux acessível a usuários sem privilégios que não confie completamente em todos eles precisa de atenção imediata.
