Uma falha no subsistema de controle de tráfego do kernel Linux pode permitir que um usuário local sem privilégios obtenha acesso de root em sistemas afetados. A
CVE-2026-46331
, apelidada de "pedit COW", é uma escrita fora dos limites na ação de edição de pacotes (act_pedit) que corrompe a memória compartilhada do page cache. Um exploit público e funcional apareceu em menos de um dia após a atribuição da CVE, em 16 de junho. A Red Hat classifica a falha como importante.
O exploit não altera o arquivo no disco. Em vez disso, ele corrompe a cópia em cache de um binário setuid root (/bin/su) na memória, injeta um pequeno payload e executa essa imagem modificada com privilégios de root. As verificações de integridade do arquivo continuam sem apontar problemas, enquanto um shell de root já está aberto. Para funcionar, o exploit precisa de duas condições, que o act_pedit possa ser carregado e que os namespaces de usuário sem privilégios estejam habilitados, o que concede ao atacante a capacidade de rede local ao namespace, CAP_NET_ADMIN, necessária para acionar a falha. Nos alvos testados em RHEL e Debian, as duas condições estavam presentes.
A ferramenta tc, de controle de tráfego do Linux, pode reescrever cabeçalhos de pacotes em trânsito usando uma ação chamada pedit. A função do kernel que faz isso, tcf_pedit_act(), deveria criar uma cópia privada dos dados antes da edição, seguindo o padrão clássico de copy-on-write. O problema é que ela verificava o intervalo gravável uma única vez, antes de os offsets finais serem conhecidos, e alguns tipos de chave de edição só resolvem seu offset em tempo de execução. Quando isso acontece, a escrita cai fora da região copiada de forma privada e o kernel acaba modificando uma página compartilhada do page cache em vez de uma cópia exclusiva. Se essa página pertencer a um arquivo em cache, a imagem do arquivo na memória é corrompida.
O padrão é conhecido. Dirty Pipe, Copy Fail, DirtyClone e Dirty Frag seguem a mesma lógica, um caminho rápido do kernel escreve em uma página que não possui exclusivamente, e o page cache sofre o impacto. A novidade aqui é o ponto de entrada. Um usuário sem privilégios pode configurar ações de tc dentro de um namespace de usuário, o que lhe concede o CAP_NET_ADMIN necessário para explorar a falha.
O autor do proof of concept relatou a exploração de usuário sem privilégios para root em RHEL 10 e Debian 13 (trixie), onde os namespaces de usuário sem privilégios vêm habilitados por padrão. No Ubuntu 24.04, foi necessário fazer a execução passar por perfis do AppArmor que ainda permitem namespaces de usuário. O Ubuntu 26.04 bloqueia esse caminho por padrão, porque seus perfis do AppArmor restringem namespaces de usuário sem privilégios, embora o kernel subjacente continue vulnerável.
As correções variam conforme o fornecedor. O Debian já corrigiu o trixie por meio do canal de segurança, embora Debian 11 e 12 ainda constem como vulneráveis. O Ubuntu lista, até 25 de junho, as versões suportadas de 18.04 a 26.04 como vulneráveis, e a Red Hat aponta RHEL 8, 9 e 10 como afetados, com o RHEL 7 fora do comunicado.
A recomendação é instalar o kernel corrigido e reiniciar o sistema, priorizando máquinas em que "usuário local" não significa usuário confiável, como hosts multiusuário, runners de CI/CD, nós Kubernetes, servidores de build e máquinas compartilhadas de pesquisa ou laboratório. Se ainda não for possível aplicar o patch, há duas medidas que interrompem a cadeia de exploração. Em sistemas que não precisam de regras tc pedit, vale verificar se o módulo está em uso com lsmod | grep act_pedit e, em seguida, impedir seu carregamento com o comando echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf. Como alternativa, é possível desativar os namespaces de usuário sem privilégios (user.max_user_namespaces=0 no RHEL, kernel.unprivileged_userns_clone=0 no Debian/Ubuntu), o que remove a capacidade de rede local no namespace exigida pelo exploit, mas quebra contêineres rootless, alguns sandboxes de CI e navegadores isolados, por isso vale testar antes.
Como a sobrescrita atinge memória em cache, as verificações de integridade de arquivos podem não detectar o problema. Limpar o page cache (echo 3 > /proc/sys/vm/drop_caches) apaga a cópia corrompida na memória, mas não desfaz o shell de root que o invasor já abriu, por isso o host deve ser tratado como comprometido.
A correção chegou à lista de discussão netdev no fim de maio, apresentada como um ajuste rotineiro de corrupção de dados, e o detalhe explorável ficou publicamente exposto por semanas sem CVE nem alerta de segurança. A CVE só foi atribuída quando a correção foi incorporada em 16 de junho, e o proof of concept armado como arma veio em menos de um dia. Em falhas de corrupção do page cache do kernel, esperar por uma regra de scanner é lento demais.
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...