A vulnerabilidade COW do pedit do Linux por trás de uma nova exploração de privilégios de root

Procurando medidas de mitigação? Pule para a seção a seguir ↓

A versão resumida

O que: Uma vulnerabilidade de escalonamento de privilégios locais no Linux chamada pedit COW (CVE-2026-46331), uma gravação sem verificação de limites na ação de controle de tráfego `act_pedit` do kernel. A função tcf_pedit_act() calcula seu intervalo de “copy-on-write” uma única vez antes de editar os cabeçalhos dos pacotes, não leva em conta o deslocamento de tempo de execução que as chaves tipadas adicionam no momento da execução e acaba gravando em uma página que nunca foi tornada privada – um COW parcial que vai parar no cache de páginas compartilhadas.

Impacto: Uma prova de conceito pública e verificada pelo autor oferece a qualquer usuário local sem privilégios um caminho pronto para obter um shell de root nos sistemas afetados, nos quais a ação `act_pedit` esteja acessível e os namespaces de usuários sem privilégios estejam disponíveis. A prova de conceito corrompe a imagem em cache do `setuid-root /bin/su` e obtém acesso direto ao root. A Red Hat classifica a falha como “Importante”.

Status: Trata-se de uma vulnerabilidade do tipo “N-day”, e não de uma surpresa divulgada no mesmo dia. A correção foi desenvolvida abertamente na lista netdev como um patch de rotina para corrupção de dados (assunto: “net/sched: correção de COW parcial no pedit que leva à corrupção do cache de páginas”), sem CVE e sem qualquer enquadramento de segurança. O CNA do kernel.org atribuiu o CVE-2026-46331 no momento da incorporação, em 16 de junho de 2026 — semanas depois que os detalhes exploráveis já haviam se tornado públicos — e um PoC explorável foi divulgado em 17 de junho. As versões mainline e estável já foram corrigidas; a Red Hat e o AlmaLinux divulgaram errata.

Gravidade: vetor de ataque local, baixa complexidade uma vez que os pré-requisitos estejam presentes, sem interação do usuário, corrupção determinística do cache de página levando aos privilégios de root e código de exploração público em funcionamento. Classe do bug: gravação fora dos limites, levando à corrupção de memória e à escalada de privilégios local. O CVSS não havia sido finalizado no momento da publicação; a classificação “Importante” da Red Hat é o indicador que deve orientar as ações.

Faça isso agora: Implemente um kernel corrigido pelo fornecedor, caso exista (RHEL 8/9/10, AlmaLinux 8, Debian 13), e reinicie o sistema. O patch do KernelCare que não requer reinicialização ainda está em fase de testes e não foi incorporado a nenhum repositório, portanto, não espere por ele. Até que você possa aplicar o patch, bloqueie o carregamento do `act_pedit` caso não utilize regras do `tc pedit` e/ou restrinja os namespaces de usuários sem privilégios. Os comandos e as considerações estão abaixo.

A versão completa

O CVE-2026-46331 é outra falha de corrupção do cache de páginas do Linux que transforma um erro de gravação do kernel em um caminho prático de acesso local ao privilégio de root. Ela está localizada no subsistema de controle de tráfego, especificamente na ação de edição de pacotes `act_pedit`, que o `tc` utiliza para reescrever bytes de cabeçalho em pacotes em trânsito.

O mais preocupante não é apenas o bug. É a forma como ele veio à tona.

O patch upstream foi discutido publicamente como uma correção para corrupção de dados, sem CVE e sem qualquer contexto óbvio de segurança. O CVE foi atribuído posteriormente, no momento da fusão, em 16 de junho, e um PoC público e explorável foi divulgado no dia seguinte. Isso torna o pedit COW um “N-day” do ponto de vista que importa para os defensores: o detalhe técnico explorável estava visível em uma lista de discussão pública antes que a maioria das equipes tivesse um CVE, uma regra de scanner, um aviso do fornecedor ou um processo de patch associado a ele.

Não detectamos essa vulnerabilidade por meio de nosso próprio monitoramento. Ela chegou por meio de uma escalação de um cliente — nunca apareceu no oss-security, e o fluxo CNA do kernel não está, no momento, em nossa lista de monitoramento. Essa lacuna é, por si só, uma lição sobre bugs do kernel do tipo “corrigir primeiro, CVE depois”, e é uma das razões pelas quais este post existe.

Isso me afeta?

Considere um host como exposto se todas as condições a seguir forem atendidas:

• O kernel contém o caminho de código vulnerável do `act_pedit`.
• O módulo act_pedit está carregado ou pode ser carregado automaticamente quando necessário.
• Os espaços de nomes de usuários sem privilégios estão habilitados, concedendo a um invasor o privilégio CAP_NET_ADMIN local ao espaço de nomes, necessário para a exploração.
• Um usuário local não confiável ou parcialmente confiável pode executar código no sistema.

O `act_pedit` é carregado automaticamente assim que uma ação `pedit tc` é configurada; portanto, um `lsmod` vazio não significa que está tudo em ordem, como pode parecer. Verifique todas as três condições:

# Is the module loaded right now?
lsmod | grep -w act_pedit

# Can it be loaded on demand?
modinfo act_pedit 2>/dev/null | head -n 1

# Are unprivileged user namespaces available?
sysctl user.max_user_namespaces kernel.unprivileged_userns_clone 2>/dev/null

Você também pode verificar se realmente utiliza a ação: o comando `tc actions list action pedit` retorna um resultado vazio em hosts que não estejam executando regras do pedit no momento. Uma saída vazia não garante sua segurança — um invasor capaz de inserir uma regra de dentro de um namespace ainda consegue acessar o caminho de execução do código —, mas indica se é seguro aplicar a medida de mitigação recomendada, que consiste na lista negra de módulos.

No RHEL e no Debian, o userns sem privilégios está aberto por padrão. No Ubuntu, ele é controlado pelo kernel por meio das opções `kernel.apparmor_restrict_unprivileged_userns` e `_unconfined`, mas esse controle é uma medida de fortalecimento de segurança, não uma correção do kernel – o PoC o contorna com um truque do `aa-exec` na versão 24.04. O Ubuntu 26.04 apresenta a mensagem “FAIL” ao ser testado com o PoC pelo mesmo motivo relacionado ao AppArmor, enquanto o kernel subjacente permanece vulnerável.

O que é o pedit COW

“pedit” é a abreviação de “packet editor” (editor de pacotes) – uma ação de controle de tráfego que permite aos administradores reescrever campos nos cabeçalhos dos pacotes à medida que estes passam pelos filtros e ações tc configurados. A função vulnerável é tcf_pedit_act(), localizada no arquivo net/sched/act_pedit.c.

Isso pertence à mesma família que Dirty Pipe, Copy Fail e Dirty Frag: uma rotina do kernel grava em uma página da qual não é proprietária exclusiva, e a gravação acaba em uma entrada do cache de páginas que corresponde a um arquivo no disco. A novidade aqui é o ponto de entrada. Em vez de um caminho rápido de criptografia ou de um caminho de descriptografia sem cópia, o gatilho é uma ação de edição de pacotes que um processo sem privilégios pode configurar de dentro de um namespace de usuário.

Em linhas gerais, o bug decorre do cálculo precoce do intervalo de pacotes graváveis. Antes de modificar os dados do pacote, o kernel chama a função skb_ensure_writable() para tornar os bytes de destino privados. A função tcf_pedit_act() calculava esse intervalo uma única vez, antes do loop sobre as chaves de edição, utilizando uma dica pré-calculada chamada tcfp_off_max_hint. A dica não levava em conta o deslocamento do cabeçalho em tempo de execução que as chaves tipadas adicionam — essas chaves resolvem seus deslocamentos em relação aos cabeçalhos L2/L3/L4 no momento da execução; portanto, o deslocamento real de gravação só é conhecido quando o loop já está em execução. Parte do destino, portanto, nunca é tornada privada. Trata-se de uma cópia parcial na gravação (copy-on-write), e a gravação na região não sujeita a COW constitui uma gravação fora dos limites e entre páginas.

Como o skb pode fazer referência a páginas sem cópia (zero-copy) obtidas por meio do sendfile, essa gravação fora dos limites pode atingir a memória compartilhada do cache de páginas que serve de suporte a um arquivo real. O kernel acredita ter tornado a memória do pacote segura para modificação; na realidade, a gravação posterior ultrapassa os limites da região que ele realmente privatizou.

Como a vulnerabilidade realmente funciona

O PoC público (sgkdev/packet_edit_meme) encadeia quatro componentes comuns — a ação `act_pedit`, buffers de socket que podem fazer referência a páginas zero-copy, espaços de nomes de usuários sem privilégios e o cache de páginas — e não requer modelagem de heap nem janela de corrida.

1. Espaço de nomes e capacidade. A partir de um espaço de nomes de usuário sem privilégios, o invasor obtém a capacidade CAP_NET_ADMIN local ao espaço de nomes — o suficiente para configurar ações de controle de tráfego dentro do espaço de nomes que controla.
2. Vinculação de controle de tráfego. Eles configuram uma ação `pedit` com chaves tipadas cujo deslocamento em tempo de execução fica fora do intervalo que a função `tcf_pedit_act()` tornou gravável, acionando a gravação COW parcial.
3. Direcionamento ao cache de página. Ao inserir referências a arquivos com “zero-copy” na pilha de rede, eles visam realizar uma gravação fora dos limites na imagem ELF em cache do comando /bin/su com permissão setuid-root.
4. Carga útil. Eles sobrescrevem o ponto de entrada armazenado em cache com um shellcode equivalente a setgid(0), setuid(0) e execve(“/bin/sh”).
5. Root. Eles saem do namespace e executam o comando `su`. O cache de páginas compartilhadas fornece a imagem corrompida, e o shellcode é executado como root.

O binário no disco nunca muda. A corrupção ocorre apenas no cache de páginas; é por isso que a análise de hash de arquivos e a perícia forense em disco podem não revelar nada, mesmo quando um shell de root já está aberto. O único pré-requisito relevante são os namespaces de usuários sem privilégios com CAP_NET_ADMIN — abertos por padrão no RHEL e no Debian, mas restritos no Ubuntu.

O que a correção do upstream altera

A correção combinada (assunto “net/sched: act_pedit: ampliar o intervalo gravável do SKB por chave”) reestrutura o caminho COW para que o intervalo gravável acompanhe o deslocamento real:

• Isso move a função skb_ensure_writable() para dentro do loop por chave, onde o deslocamento real de gravação já é conhecido.
• Isso adiciona uma verificação de estouro na aritmética de deslocamento e protege a função `offset_valid()` contra o valor `INT_MIN`, caso em que a negação é indefinida.
• Para deslocamentos negativos — como edições no cabeçalho da Ethernet na entrada —, ele usa a função skb_cow() para aplicar o COW ao espaço livre.
• Isso lineariza os skbs que transportam fragmentos compartilhados na parte inicial, de modo que uma página de cópia zero não possa ser corrompida sem que se perceba.

Trata-se de uma alteração isolada em uma única função. O patch sem reinicialização do KernelCare é uma adaptação genuína dessa correção do upstream, em vez de um equivalente conservador do kpatch: ele reconstrói o caminho COW dentro de tcf_pedit_act() com a mesma lógica de skb_ensure_writable() / skb_cow() por chave e as mesmas proteções de deslocamento.

Por que esse bug passou despercebido tão facilmente

O “pedit-cow” nunca foi apresentado aos defensores como uma emergência específica. Parecia uma correção de corrupção de dados de rede e foi tratado como tal ao longo do processo.

Isso é importante porque a maioria dos fluxos de trabalho de correção monitora feeds do CVE, alertas de fornecedores, o canal oss-security e atualizações de scanners. Esse problema seguiu um caminho em que a implicação de segurança só ficou evidente posteriormente: a correção foi identificada primeiro, o CVE chegou na fase de mesclagem e o PoC surgiu em menos de um dia. Para bugs do kernel dessa categoria, a abordagem “correção primeiro, CVE depois” abre uma janela de oportunidade em que invasores e pesquisadores especializados compreendem a possibilidade de exploração antes mesmo que os processos corporativos comuns de correção registrem o problema.

Conclusão prática: trate as correções públicas no kernel relacionadas à corrupção do cache de páginas, COW parcial, gravações sem cópia e tratamento de intervalos de SKB graváveis como potencialmente relevantes para a segurança antes que um CVE ou PoC seja divulgado.

Quem é afetado

A vulnerabilidade se resume a três aspectos: se o `act_pedit` consegue ser carregado, se usuários sem privilégios têm permissão para executá-lo e se a sua distribuição foi fornecida com um kernel corrigido.

Exploração confirmada por um PoC público (verificado pelo autor, sem privilégios de root):

• RHEL 10.0 na versão 6.12.0-228.el10 – não é necessário usar nenhum sinalizador; as contas de usuário estão abertas por padrão
• Debian 13 trixie na versão 6.12.90+deb13.1 – não é necessário usar nenhuma opção
• Ubuntu 24.04.4 na versão 6.17.0-22 – requer a contornamento do parâmetro –ubuntu aa-exec userns

O Ubuntu 26.04 (7.0.0-14) retorna “FAIL”, mas isso se deve ao fato de o fortalecimento de usuários do AppArmor estar funcionando corretamente, e não a um kernel corrigido. O kernel subjacente ainda está vulnerável.

Correção feita pelo fornecedor (implemente o kernel corrigido e reinicie o sistema):

• RHEL 10 – RHSA-2026:27288
• RHEL 9 – RHSA-2026:27789
• RHEL 8 – RHSA-2026:27353; a versão recompilada para o AlmaLinux 8 é a ALSA-2026:27353 (lançada em 22 de junho). RHSA-2026:27355 é a variante 8.8 EUS/TUS.
• Debian 13 trixie – DSA-6355-1 (publicado em 21 de junho)

Além da linha principal e dos backports estáveis.

Afetados, mas ainda sem correção do fornecedor – os servidores nos quais a mitigação provisória é a única opção disponível no momento e nos quais a cobertura de patches que não exigem reinicialização será mais importante assim que forem lançados:

• Debian 11 e 12
• Ubuntu bionic até noble (a versão 24.04.4 é um alvo confirmado para o PoC)

Não afetados ou ainda em aberto:

• RHEL 7 / CentOS 7 – não afetados.
• Oracle UEK 6 e UEK 7 – status “em aberto” em nosso tópico de desenvolvimento.

Aja agora para mitigar

A medida mais segura é proteger imediatamente o kernel em execução. Existem três medidas práticas, em ordem de preferência.

1. Atualização ou atualização sem reinicialização

Instale o kernel corrigido pelo fornecedor, caso exista, e reinicie o sistema assim que for operacionalmente possível. Dê prioridade aos hosts nos quais é executado código parcialmente confiável: nós do Kubernetes, executores de CI/CD, hospedagem compartilhada, sistemas de desenvolvimento e compilação, plataformas multilocatárias e hosts de contêineres que aceitam cargas de trabalho não confiáveis.

Os patches do KernelCare que não exigem reinicialização para o CVE-2026-46331 estão em desenvolvimento ativo e em fase de testes em comparação com a correção do upstream. De acordo com o status de cobertura mais recente, nada foi lançado ainda nos feeds de teste, principal ou ePortal. Assim que uma compilação for disponibilizada, verifique-a:

kcarectl --patch-info | grep -i 'CVE-2026-46331'
kcarectl --info | grep kpatch-build-time      # build dated on or after the release

2. Desative o act_pedit caso você não o utilize

O `act_pedit` é carregado automaticamente assim que uma ação `pedit tc` é configurada. Se você não tiver regras `tc pedit` em execução — o que ocorre na maioria dos hosts —, impeça que ele seja carregado.

O boletim da Red Hat (RHSB-2026-008) sugere uma lista de bloqueio na inicialização:

echo 'blacklist act_pedit' > /etc/modprobe.d/blacklist-act-pedit.conf

Uma lista negra apenas impede o carregamento automático na inicialização. Como o act_pedit pode ser carregado automaticamente sob demanda no momento em que uma regra o referencia, o bloqueio mais confiável é uma substituição na instalação que direcione o módulo para /bin/true:

echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf

Em seguida, verifique se ela está carregada e a descarregue somente se nenhuma regra de tráfego ativa depender dela:

lsmod | grep -w act_pedit && sudo rmmod act_pedit
lsmod | grep -w act_pedit || echo "act_pedit not loaded"

Para reverter, remova o arquivo:

sudo rm /etc/modprobe.d/disable-act_pedit.conf

Efeito colateral: qualquer configuração de controle de tráfego que utilize a ação `pedit` não será carregada enquanto o bloqueio estiver ativo. Algumas configurações de contêineres/CNI e QoS dependem disso; portanto, não aplique essa alteração em hosts que precisem das regras `tc pedit`. Verifique com o comando `tc actions list action pedit` antes de implementar a alteração em grande escala.

3. Restringir os espaços de nomes de usuários sem privilégios

A vulnerabilidade requer um namespace de usuário sem privilégios para obter o CAP_NET_ADMIN local ao namespace. Fechar namespaces de usuário sem privilégios interrompe a cadeia pública, independentemente do estado do módulo.

# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf

# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf

No Ubuntu, você pode, em vez disso, tornar mais restritivos os controles existentes do AppArmor (kernel.apparmor_restrict_unprivileged_userns / _unconfined), o que é o que bloqueia o PoC na versão 26.04 por padrão.

Nota de compatibilidade: os espaços de nomes de usuários sem privilégios são exigidos por ambientes de execução de contêineres sem root, várias sandboxes de CI, o comando `unshare(1)` sem privilégios, navegadores em sandbox e o Flatpak. São aceitáveis em cargas de trabalho fortificadas ou de hospedagem, mas podem causar interrupções em hosts de desenvolvedores e de contêineres. Teste antes de uma implantação em larga escala.

Momento decisivo

Se o host não executar nenhuma regra do tc pedit → bloqueie o act_pedit; essa é a alteração mais restrita. Se for necessário o pedit, mas não os contêineres sem root nem o unshare sem privilégios → restrinja os usuários em vez disso. Se for necessário ambos → o patch ou o patch sem reinicialização é a única solução viável; isole a execução local não confiável até lá.

Patch KernelCare sem reinicialização

Status em 23/06/2026, às 18h30 UTC: em fase de testes ativos sob o ticket principal KCARE-27230. Ainda não há lançamento nos feeds de teste, principal ou ePortal. O trabalho por distribuição é acompanhado nos tickets KCARE-27167 (EL10), KCARE-27223 (EL9), KCARE-27159 (EL8) e KCARE-27204 (Debian 13).

Assim que uma compilação for enviada para o feed de testes, aplique-a com:

kcarectl --update --prefix test

Após a validação, ele será entregue na próxima execução programada, ou você pode baixá-lo sob demanda:

kcarectl --update

Verifique:

kcarectl --patch-info | grep -i 'CVE-2026-46331'

Detecção

Não há nenhuma assinatura confiável pós-comprometimento para o pedit-cow. A corrupção ocorre no cache de páginas; o binário no disco permanece intacto, e as evidências desaparecem assim que as páginas em cache são removidas ou o sistema é reiniciado. As verificações de integridade de arquivos são um indicador pouco confiável nesse caso.

Os sinais comportamentais que vale a pena observar:

• Carregamento inesperado do módulo act_pedit em hosts que não executam a edição de pacotes para controle de tráfego.
• Atividade incomum de tc por parte de usuários ou processos que normalmente nunca configuram a rede.
• Criação de espaços de nomes de usuário sem privilégios pouco antes da execução do binário setuid.
• Execução de comandos `su`, `sudo` ou do shell que ocorra após uma ação de controle de tráfego sem motivo legítimo.

Auditar a execução do tc e o carregamento de módulos:

auditctl -w /sbin/tc -p x -k tc_exec
auditctl -w /usr/sbin/tc -p x -k tc_exec
grep act_pedit /proc/modules

Se você suspeitar de exploração, esvazie o cache da página para forçar a recarga dos bytes originais a partir do disco:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Considere isso como uma medida de contenção, não de remediação. Se um invasor já tiver obtido acesso de root, a remoção forçada não elimina a persistência que ele estabeleceu posteriormente. Qualquer host em que um usuário local não confiável tenha tido acesso ao shell durante o período de exposição deve ser tratado como potencialmente comprometido.

Por que bugs como o pedit-cow continuam reaparecendo

pedit-cow, Dirty Pipe, Copy Fail e Dirty Frag diferem nos detalhes, mas compartilham um padrão: um caminho rápido voltado para o desempenho que faz uma suposição errada sobre se uma página é segura para gravação. Em cada caso, uma gravação atingiu uma página que o kernel acreditava ser de sua propriedade, e o cache de páginas foi afetado porque é compartilhado por padrão — todo leitor de um arquivo vê a mesma página física; assim, uma única gravação incorreta nela pode se tornar visível para um código privilegiado que esteja lendo bytes executáveis.

Essas falhas são perigosas justamente porque transformam a “corrupção da memória local” em algo prático. Um invasor não precisa contornar as permissões de arquivo nem modificar nada no disco. Basta corromper a cópia armazenada em cache por tempo suficiente para que um código com privilégios a leia ou a execute.

A solução mais profunda não é “parar de otimizar”. Trata-se de garantias mais robustas de propriedade de páginas em todas as rotas de gerenciamento de memória do kernel — um trabalho demorado, pois envolve as partes do kernel mais sensíveis ao desempenho. O pedit-cow não será o último bug dessa família. Isso também mostra por que a resposta no mesmo dia está se tornando cada vez mais difícil: uma vulnerabilidade pode passar de um patch aparentemente comum para um CVE e, em seguida, para uma exploração pública de privilégios de root antes que muitas organizações tenham uma visão clara da situação operacional.

Lista de verificação de medidas corretivas priorizadas

1. Correção. Implemente o kernel corrigido pelo fornecedor (RHEL 8/9/10, AlmaLinux 8, Debian 13) e reinicie o sistema. Não espere pela correção do KernelCare que não requer reinicialização – ela ainda não está disponível em nenhum repositório.
2. Aplique medidas de mitigação onde não for possível aplicar patches. Bloqueie o `act_pedit` se você não tiver regras `tc pedit` em execução, ou restrinja usuários sem privilégios, se for possível.
3. Faça uma auditoria no acesso local. Verifique quem possui acesso ao shell em servidores 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.
4. Faça uma busca. Aplique as heurísticas de detecção à janela de exposição, começando pela postagem na lista de discussão do final de maio em diante.
5. Reinicie o sistema após a aplicação do patch. Isso limpa todas as páginas em cache potencialmente corrompidas, juntamente com o kernel antigo.

Referências

• NVD – CVE-2026-46331: https://nvd.nist.gov/vuln/detail/CVE-2026-46331
• Registro no CVE.org – CVE-2026-46331
• Aviso do GitHub GHSA-cr2w-747q-47qc
• Red Hat RHSB-2026-008 – Escalada de privilégios no Traffic Control e a página do CVE da Red Hat
• Erratas do fornecedor: RHSA-2026:27288 (RHEL 10), RHSA-2026:27789 (RHEL 9), RHSA-2026:27353 (RHEL 8 = AlmaLinux ALSA-2026:27353; RHSA-2026:27355 é a variante 8.8 EUS/TUS), DSA-6355-1 (Debian 13)
• Rastreador de Segurança do Debian – CVE-2026-46331
• PoC público (Massimiliano Oldani, 17/06/2026): https://github.com/sgkdev/packet_edit_meme
• Tópico do netdev: espelhos do LKML v2 e v3; raiz do tópico no Spinics
• Stable fix commits (git.kernel.org/stable/c/<hash>): 899ee91156e5, 2bec122b9fb9, 3dee9d0c198f, b198ed4e5258
• Acompanhamento do KernelCare: caso-mestre KCARE-27230; patch sem reinicialização CL gerrit 256818; por distribuição KCARE-27167 / 27223 / 27159 / 27204

Aplique patches em qualquer kernel, sem necessidade de reinicialização. Se você ainda não é usuário do KernelCare, este é um bom momento para descobrir como a aplicação de patches sem reinicialização protege sistemas Linux críticos, sem a necessidade de janelas de manutenção de emergência ou tempo de inatividade.

Saiba mais sobre o KernelCare aqui →