Novo exploit no Linux permite obter root sem tocar nos arquivos em disco
Uma falha grave no subsistema de controle de tráfego do kernel Linux está permitindo que usuários locais sem privilégios conquistem acesso root em diversas distribuições, sem alterar um único byte dos arquivos armazenados em disco. O problema, catalogado como CVE-2026-46331 e apelidado de “pedit COW”, explora uma condição de escrita fora dos limites (out-of-bounds write) na ação de edição de pacotes `act_pedit`, que acaba corrompendo memória compartilhada no cache de páginas (page cache).
A vulnerabilidade ganhou destaque rapidamente porque um exploit funcional foi tornado público cerca de 24 horas após a atribuição oficial do CVE, em 16 de junho. Fornecedores classificaram o bug como de alta severidade, já que seu impacto prático é uma escalada local de privilégios dentro do subsistema de controle de tráfego (traffic control) do kernel Linux, com possibilidade de elevação a root em sistemas reais de produção.
Como o ataque funciona sem modificar arquivos em disco
O aspecto mais preocupante do “pedit COW” é o vetor pouco convencional: o exploit não precisa escrever nada no arquivo real armazenado em disco. Em vez disso, ataca a cópia daquele arquivo que está temporariamente mantida na memória pelo kernel – o page cache.
Na exploração demonstrada publicamente, o alvo é um binário setuid root clássico, como `/bin/su`. Esses binários são executáveis que, por design, rodam com privilégios de root mesmo quando chamados por usuários comuns. O exploit manipula a cópia em cache desse binário na memória, corrompendo seu conteúdo de forma controlada.
A partir da modificação em memória, o atacante consegue executar uma “imagem” temporariamente adulterada desse executável, já com privilégios elevados, e assim abrir um shell com acesso root. Como o arquivo persistente no disco permanece intacto, ferramentas tradicionais de verificação de integridade – que comparam hashes ou conteúdos de arquivos em disco – não detectam qualquer anomalia. O sistema parece íntegro, enquanto a cópia carregada em RAM está sendo explorada.
Condições necessárias para a exploração
A cadeia de ataque depende de dois pré-requisitos principais:
1. Disponibilidade do módulo act_pedit
O módulo responsável pela ação de edição de pacotes, `act_pedit`, precisa estar presente no sistema ou ser carregável pelo kernel. Sem ele, o caminho específico de código com o bug não é acionado.
2. Namespaces de usuário sem privilégios habilitados
É essencial que namespaces de usuário para contas não privilegiadas estejam ativados. Isso permite que um usuário comum crie um namespace próprio e dentro dele obtenha capacidades de rede locais ao namespace, como a `CAP_NET_ADMIN`, necessária para configurar regras de controle de tráfego e disparar a vulnerabilidade no subsistema de traffic control.
Nos testes descritos pelo autor da prova de conceito, essas condições estavam presentes em sistemas baseados em RHEL e Debian, o que amplia o alcance prático do problema. A falha é especialmente crítica em ambientes onde “usuário local” não é sinônimo de “usuário confiável”:
– servidores multi-tenant;
– runners de CI/CD;
– nós de clusters Kubernetes;
– máquinas de build e pipelines de compilação;
– ambientes de pesquisa e ensino compartilhados;
– laboratórios internos com acesso concedido a múltiplas equipes.
Nesses contextos, basta uma conta de usuário comum comprometida – por phishing, malware, credenciais vazadas ou abuso interno – para que o invasor tente escalar até root usando o exploit.
Onde está o erro no kernel: tc, pedit e copy-on-write
O problema nasce no funcionamento da ferramenta `tc`, usada no Linux para configurar políticas de controle de tráfego (traffic control) na pilha de rede. Um dos recursos de `tc` é o `pedit`, que permite reescrever cabeçalhos de pacotes em trânsito, alterando campos como endereços, portas ou flags.
Dentro do kernel, a função responsável por essa ação é a `tcf_pedit_act()`. A lógica correta exigiria que, antes de alterar qualquer dado, o kernel criasse uma cópia privada da área de memória a ser modificada, seguindo o padrão “copy-on-write” (COW). O objetivo é garantir que alterações feitas para um contexto não vazem para outros que compartilham a mesma página de memória.
A falha surge porque a validação da faixa de memória gravável é feita somente uma vez, antes de todos os offsets finais serem conhecidos. Algumas chaves de edição de pacote têm seus offsets resolvidos apenas em tempo de execução, durante o processamento efetivo do pacote. Quando essa resolução tardia acontece, a escrita pode extrapolar a área que foi copiada privadamente. Em vez de alterar apenas a cópia isolada, o kernel acaba escrevendo em uma página compartilhada do page cache.
Se essa página compartilhada corresponder à imagem em cache de um arquivo, o conteúdo daquele arquivo na memória pode ser corrompido – mesmo que o arquivo em disco esteja intocado. Explorando cuidadosamente esse comportamento, é possível transformar a corrupção de memória em uma escalada de privilégios ao corromper um binário setuid root e, na sequência, executá-lo.
Semelhanças com Dirty Pipe e outras falhas de page cache
Tecnicamente, o padrão lembra vulnerabilidades anteriores ligadas ao page cache, como Dirty Pipe, Copy Fail, DirtyClone e Dirty Frag. Em todas elas, algum “caminho rápido” do kernel (fast path), projetado para alto desempenho, acabava escrevendo em páginas de memória que não eram de uso exclusivo do chamador, afetando dados mantidos em cache.
A diferença do “pedit COW” está no ponto de entrada: em vez de envolver diretamente operações de arquivos, o gatilho passa pelo subsistema de controle de tráfego de rede (`tc`), pela ação `act_pedit` e pelo uso de namespaces de usuário. Isso permite que um usuário sem privilégios, mas com namespaces abertos, obtenha as capacidades de rede necessárias dentro de seu próprio namespace para explorar o bug, sem depender de privilégios administrativos globais no sistema.
Distribuições e versões afetadas
De acordo com os testes de prova de conceito divulgados, foi possível obter escalada de privilégios de usuário sem privilégios para root nas seguintes situações:
– RHEL 10: exploração bem-sucedida a partir de conta comum, com namespaces de usuário habilitados.
– Debian 13 (trixie): vulnerável com namespaces de usuário sem privilégios ativos por padrão.
No Ubuntu 24.04, a exploração também foi viável, mas exigiu contornar a camada de perfis AppArmor que ainda permitem o uso de namespaces de usuário em certos contextos.
Já o Ubuntu 26.04 adota, por padrão, perfis AppArmor mais restritivos, que limitam namespaces de usuário sem privilégios. Nesses sistemas, o caminho mais direto de exploração é bloqueado pela política de segurança, embora o kernel subjacente continue tecnicamente vulnerável ao bug.
Quanto à distribuição de patches:
– O Debian já disponibilizou correção para o trixie por meio de seus canais de segurança; Debian 11 e 12 ainda são listados como vulneráveis no material original.
– O Ubuntu registra como vulneráveis as versões suportadas de 18.04 até 26.04, em informação atualizada em 25 de junho.
– A Red Hat indica que RHEL 8, 9 e 10 são afetados; RHEL 7 não aparece na lista de versões impactadas nesse boletim específico.
Principais recomendações de mitigação
A medida mais eficaz continua sendo a atualização do kernel para uma versão corrigida, seguida de reinicialização completa do sistema. A correção atua no código do kernel, portanto só terá efeito quando o novo kernel estiver efetivamente carregado e em execução.
A prioridade de aplicação de patches deve ser máxima em:
– ambientes multi-tenant com muitos usuários por máquina;
– servidores de aplicação expostos à internet;
– infraestruturas de nuvem privada ou pública;
– nós de clusters Kubernetes e plataformas de orquestração de contêineres;
– servidores de CI/CD e de build usados por times de desenvolvimento distintos.
Enquanto o patch não puder ser aplicado – por restrições de janela de manutenção, dependências ou riscos operacionais – algumas medidas de contenção podem reduzir ou dificultar a exploração:
1. Restringir namespaces de usuário sem privilégios
Desabilitar ou limitar a criação de namespaces de usuário por contas comuns reduz significativamente a superfície de ataque. Distribuições já oferecem parâmetros de kernel e opções de configuração para controlar esse recurso.
2. Controlar o carregamento de módulos de rede
Se possível, impedir que usuários comuns influenciem o carregamento do módulo `act_pedit` ou restringir o uso de `tc` em contextos não essenciais pode bloquear o ponto de entrada da vulnerabilidade.
3. Endurecer perfis de segurança (AppArmor, SELinux, etc.)
Perfis mais agressivos podem impedir que processos não confiáveis obtenham capacidades de rede avançadas, mesmo dentro de namespaces, adicionando mais uma camada de proteção em torno do subsistema de traffic control.
4. Segregar workloads sensíveis
Onde não for viável desabilitar namespaces por completo – por exemplo, em plataformas de contêineres – é importante isolar workloads de alto risco, como código de terceiros, jobs de CI não confiáveis ou ambientes de sandbox, em nós específicos, facilitando a aplicação de políticas mais rígidas e monitoramento dedicado.
O que torna essa falha difícil de detectar
Um ponto crítico do “pedit COW” é o impacto limitado ao nível de memória: o arquivo em disco permanece imaculado. Soluções de segurança que baseiam sua detecção exclusivamente em:
– varredura de integridade de arquivos;
– comparação de hashes;
– monitoramento de alterações em disco;
tendem a não perceber a manipulação feita no page cache. O binário setuid root afetado volta ao estado normal assim que a página é descartada da memória ou o sistema é reinicializado, apagando evidências diretas do ataque.
Isso reforça a importância de controles em outras camadas:
– monitoramento de uso anômalo de `tc` e do subsistema de traffic control;
– detecção de tentativas suspeitas de escalada de privilégios;
– logging detalhado de criação e uso de namespaces de usuário;
– auditoria de execuções de binários setuid em contextos incomuns.
Impacto para provedores, equipes de DevOps e segurança
Para provedores de hospedagem, plataformas de nuvem e equipes de DevOps, a vulnerabilidade acende um alerta relevante. Sistemas que executam múltiplos contêineres, jobs de integração contínua ou aplicações de times diferentes no mesmo host físico ou virtual são particularmente sensíveis a falhas de escalada local.
Um atacante que comprometa qualquer workload com acesso de usuário comum passa a ter um caminho relativamente curto até o root do host, caso o exploit seja bem-sucedido. A partir daí, torna-se possível:
– acessar dados de outros contêineres ou serviços hospedados no mesmo nó;
– manipular pipelines de build e injetar código malicioso em artefatos;
– comprometer chaves, tokens e credenciais armazenadas no host;
– pivotar para outros sistemas da infraestrutura interna.
Por isso, além da aplicação do patch, é recomendável revisar a arquitetura de isolamento: avaliar se workloads de diferentes níveis de confiança devem realmente compartilhar o mesmo host, e se as políticas de rede, capacidades e namespaces estão devidamente restringidas.
Caminho daqui para frente
Falhas como o “pedit COW” mostram que, mesmo componentes considerados maduros do kernel, como subsistemas de rede e cache de páginas, ainda podem esconder bugs de alto impacto quando combinados a recursos avançados como namespaces e capacidades.
Para administradores de sistemas e equipes de segurança, o recado é direto:
– manter o kernel atualizado;
– tratar falhas de escalada local com a mesma seriedade dada a vulnerabilidades remotas;
– revisar políticas de isolamento e uso de namespaces;
– reforçar camadas de monitoramento que não dependam exclusivamente de integridade de arquivos em disco.
Em um cenário onde o limite entre “usuário local” e “ator de ameaça” é cada vez mais tênue – especialmente em ambientes compartilhados e em nuvem – vulnerabilidades de page cache como o “pedit COW” tendem a continuar sendo um vetor atraente para ataques avançados. Antecipar-se com correções rápidas, hardening e boas práticas de segmentação é a melhor resposta possível.