Novo exploit do Linux consegue obter root sem modificar arquivos no disco

Uma vulnerabilidade no subsistema de controle de tráfego do kernel Linux pode permitir que um usuário local sem privilégios obtenha acesso root em sistemas afetados. A falha, rastreada como CVE-2026-46331 e apelidada de “pedit COW”, envolve uma escrita fora dos limites na ação de edição de pacotes act_pedit, capaz de corromper memória compartilhada do page cache.

A vulnerabilidade recebeu atenção imediata porque um exploit funcional e público surgiu cerca de um dia após a atribuição do CVE, em 16 de junho. A Red Hat classifica o problema como importante e descreve o impacto como uma escalada local de privilégios no subsistema de traffic control do kernel Linux.

O ponto mais sensível da exploração está no fato de que o ataque não precisa alterar diretamente o arquivo no disco. Em vez disso, o exploit corrompe a cópia em cache de um binário setuid root, como /bin/su, na memória. A partir dessa alteração temporária no page cache, o invasor consegue executar uma imagem modificada com privilégios elevados e abrir um shell root.

Esse comportamento dificulta a detecção por ferramentas tradicionais de verificação de integridade de arquivos. Como o binário persistente no disco não é modificado, checagens baseadas apenas em hash ou comparação de arquivos podem indicar que tudo está normal, mesmo que a cópia carregada em memória tenha sido manipulada durante a exploração.

A cadeia de ataque depende de duas condições principais. A primeira é que o módulo act_pedit esteja disponível ou possa ser carregado no sistema. A segunda é que namespaces de usuário sem privilégios estejam habilitados, permitindo que o atacante obtenha uma capacidade de rede local ao namespace, como CAP_NET_ADMIN, necessária para acionar o bug.

Nos testes relatados pelo autor da prova de conceito, essas condições estavam presentes em sistemas RHEL e Debian. Isso torna a falha especialmente relevante para ambientes em que “usuário local” não significa necessariamente “usuário confiável”, como servidores multi-tenant, runners de CI/CD, nós Kubernetes, máquinas de build, ambientes de pesquisa compartilhados e laboratórios.

O problema está relacionado ao funcionamento da ferramenta tc, usada no Linux para controle de tráfego de rede. Um de seus recursos, o pedit, permite reescrever cabeçalhos de pacotes em trânsito. No kernel, a função tcf_pedit_act() deveria criar uma cópia privada da área de dados antes de modificá-la, seguindo o padrão conhecido como copy-on-write, ou COW.

A falha ocorre porque a validação da faixa gravável é feita uma vez, antes que todos os offsets finais sejam conhecidos. Algumas chaves de edição resolvem seus offsets apenas em tempo de execução. Quando isso acontece, a escrita pode atingir uma região fora da área copiada de forma privada, levando o kernel a modificar uma página compartilhada do page cache em vez de uma cópia isolada.

Se essa página compartilhada pertencer à imagem em cache de um arquivo, o conteúdo em memória desse arquivo pode ser corrompido. No caso explorado publicamente, o alvo é um binário setuid root, o que permite converter uma corrupção de memória em uma escalada de privilégios para root.

O padrão técnico lembra vulnerabilidades anteriores de corrupção do page cache, como Dirty Pipe, Copy Fail, DirtyClone e Dirty Frag. Em todos esses casos, um caminho rápido do kernel acaba escrevendo em uma página que não possui de forma exclusiva, afetando dados mantidos no cache. A diferença no pedit COW está no ponto de entrada: a combinação entre traffic control, act_pedit e namespaces de usuário permite que um usuário sem privilégios alcance a capacidade necessária para acionar a falha.

Em relação aos sistemas afetados, o autor da prova de conceito relatou exploração de usuário sem privilégios para root no RHEL 10 e no Debian 13, também conhecido como trixie, onde namespaces de usuário sem privilégios estão abertos por padrão. No Ubuntu 24.04, a exploração exigiu roteamento por perfis AppArmor que ainda permitem namespaces de usuário. Já o Ubuntu 26.04 bloqueia esse caminho por padrão porque seus perfis AppArmor restringem namespaces de usuário sem privilégios, embora o kernel subjacente continue vulnerável.

A situação dos patches varia conforme o fornecedor. O Debian corrigiu o trixie por meio de seu canal de segurança, enquanto Debian 11 e 12 ainda aparecem como vulneráveis no material original. O Ubuntu lista versões suportadas de 18.04 a 26.04 como vulneráveis em 25 de junho. A Red Hat informa que RHEL 8, 9 e 10 são afetados; o RHEL 7 não aparece listado no boletim citado.

A principal recomendação é instalar o kernel corrigido e reiniciar os sistemas afetados. A reinicialização é necessária porque a correção do kernel precisa estar em execução para eliminar o risco. A prioridade deve ser dada a ambientes compartilhados, servidores com usuários locais não totalmente confiáveis, hosts que executam cargas de trabalho de terceiros e plataformas de automação que rodam código de múltiplas origens.

Quando a aplicação imediata do patch não for possível, há duas mitigações que reduzem a cadeia de exploração. A primeira é impedir o carregamento do módulo act_pedit em sistemas que não utilizam regras tc pedit. Administradores podem verificar se o módulo está em uso e, se não houver dependência operacional, bloqueá-lo por configuração do sistema.

A segunda mitigação é desabilitar namespaces de usuário sem privilégios. Em distribuições baseadas em RHEL, isso pode envolver o ajuste de user.max_user_namespaces=0. Em Debian e Ubuntu, a configuração frequentemente citada é kernel.unprivileged_userns_clone=0. Essa medida remove a capacidade local ao namespace necessária para o exploit, mas pode afetar containers rootless, sandboxes de CI, navegadores com isolamento baseado em namespace e outras aplicações modernas. Por isso, precisa ser testada antes de adoção ampla.

Como o ataque manipula memória em cache, verificações de integridade de arquivos podem não detectar a exploração. Limpar o page cache pode remover a cópia corrompida em memória, mas não desfaz ações já executadas pelo invasor nem encerra um shell root obtido anteriormente. Em casos de suspeita de exploração, o host deve ser tratado como comprometido e passar por resposta a incidente.

Outro aspecto relevante é o tempo entre a correção técnica e a exposição pública do risco. A correção entrou na lista de discussão netdev no fim de maio, inicialmente tratada como um patch rotineiro de corrupção de dados. O detalhe explorável permaneceu publicamente visível por semanas antes da atribuição formal do CVE em 16 de junho. Pouco depois, uma prova de conceito funcional foi publicada.

O caso mostra por que falhas de corrupção no page cache do kernel exigem resposta rápida. Quando um problema desse tipo deixa de ser apenas uma correção de estabilidade e passa a permitir escalada local de privilégios, esperar por regras de scanner ou ciclos longos de validação pode ser insuficiente. Para equipes de infraestrutura e segurança, a prioridade deve ser identificar sistemas expostos, aplicar correções de kernel, revisar o uso de namespaces de usuário e reduzir a superfície de ataque associada ao act_pedit.