Host Deep Dive #1 — Copy Fail (CVE-2026-31431): como um bug de cópia no kernel pode virar root
A CVE-2026-31431 está no kernel Linux, no socket de cripto AF_ALG. Um processo sem privilégios pode alterar o page cache e fazer outros processos lerem um arquivo que não é o que está no disco.


“Copy Fail” é o nome associado à vulnerabilidade CVE-2026-31431, uma falha de escalada de privilégios no kernel Linux.
Em termos simples, a vulnerabilidade permite que um processo que normalmente não possui privilégios consiga fazer o kernel alterar temporariamente, na memória, o conteúdo de um arquivo. O arquivo no disco pode continuar intacto, mas outros processos podem acabar enxergando a versão modificada que está no cache.
Em determinadas condições, esse comportamento pode ser usado para alterar o código de um programa privilegiado e transformar uma execução como usuário comum em uma execução como root.
A vulnerabilidade foi introduzida em 2017, durante o desenvolvimento do kernel Linux 4.14, e permaneceu presente por cerca de nove anos em diferentes versões e distribuições. A falha foi corrigida em 2026, com correções também disponibilizadas para diferentes ramos mantidos do kernel.
Por afetar um componente do próprio kernel, o problema não está limitado a uma única distribuição. Sistemas baseados em Linux, como Ubuntu, Debian, Red Hat, SUSE e Amazon Linux, podem estar vulneráveis caso utilizem um kernel afetado e ainda não corrigido.
Ela foi descoberta por Taeyang Lee, pesquisador da empresa de segurança Theori. A divulgação pública ocorreu em 29 de abril de 2026.
Onde está o bug
A vulnerabilidade está no AF_ALG, uma interface do Linux que permite que programas utilizem operações criptográficas implementadas pelo kernel.
Pense no AF_ALG como uma forma de uma aplicação dizer ao kernel:
“Kernel, faça esta operação criptográfica para mim.”
O código afetado fica no módulo algif_aead.
O problema aparece durante o caminho utilizado para movimentar os dados dessa operação. Em determinadas condições, uma escrita que deveria acontecer em um buffer específico pode acabar atingindo páginas pertencentes ao page cache.
E o que é o page cache?
É uma área da memória RAM utilizada pelo Linux para manter temporariamente dados de arquivos.
Por exemplo, quando um programa lê arquivo.txt, o kernel pode colocar o conteúdo desse arquivo na memória:
DISCO
│
│ lê arquivo
▼
┌──────────────┐
│ PAGE CACHE │
│ RAM │
└──────┬───────┘
│
▼
programa
Se outro processo precisar ler o mesmo arquivo, o kernel pode reutilizar esses dados que já estão na RAM em vez de acessar o disco novamente.
O Copy Fail explora justamente esse mecanismo.
Por que o arquivo “muda” sem gravar no disco
Essa é uma das partes mais importantes da vulnerabilidade.
Imagine que temos um arquivo no disco:
DISCO
/usr/bin/programa
[ conteúdo original ]
O kernel pode possuir uma página desse arquivo no page cache:
RAM
PAGE CACHE
[ conteúdo original ]
Com o Copy Fail, essa página na memória pode ser alterada:
DISCO
[ conteúdo original ]
RAM
PAGE CACHE
[ conteúdo ALTERADO ]
O arquivo no disco não precisa ter sido modificado.
O problema é que o kernel pode continuar utilizando aquela página em memória para atender novas leituras.
Assim, um processo pode pedir “leia /usr/bin/programa” e receber o conteúdo que está atualmente no page cache, que pode ser diferente daquele armazenado no disco.
É como se existissem duas versões temporárias do mesmo arquivo:
DISCO
│
│ conteúdo original
▼
┌─────────────┐
│ ARQUIVO │
└─────────────┘
RAM
│
│ conteúdo alterado
▼
┌─────────────┐
│ PAGE CACHE │
└─────────────┘
Essa diferença entre o que está no disco e o que o kernel possui em memória é fundamental para entender o Copy Fail.
Como isso vira escalada de privilégio
Até aqui, temos apenas uma alteração de dados na memória.
Para transformar isso em escalada de privilégio, é necessário atingir um arquivo que tenha algum significado especial.
Um dos alvos possíveis são os executáveis setuid.
No Linux, um programa com setuid pode ser executado por um usuário comum, mas iniciar o processo utilizando os privilégios do proprietário do arquivo.
Quando o proprietário é root, temos algo parecido com:
usuário comum
│
▼
programa setuid
│
▼
processo com privilégios de root
Normalmente, o usuário não consegue alterar o código desse programa.
O Copy Fail introduz uma situação diferente:
usuário comum
│
▼
explora a falha
│
▼
altera página no page cache
│
▼
programa privilegiado
│
▼
executa conteúdo alterado
│
▼
privilégios elevados
O ponto importante é que o atacante não precisa necessariamente modificar o arquivo no disco.
Ele explora o fato de que o programa pode ser carregado a partir de uma página que já foi alterada na memória.
Por isso uma pequena corrupção de memória pode acabar tendo um impacto muito maior.
Por que isso é uma escalada local
Copy Fail não deve ser confundido com um RCE remoto.
A vulnerabilidade, por si só, não significa que alguém na internet possa simplesmente enviar uma requisição para um servidor e virar root.
O cenário é mais parecido com:
1. atacante consegue executar código
│
▼
2. código roda como usuário comum
│
▼
3. explora o Copy Fail
│
▼
4. manipula o page cache
│
▼
5. consegue elevar seus privilégios
Ou seja, o atacante normalmente já precisa ter algum nível de execução na máquina.
Isso pode acontecer, por exemplo, depois do comprometimento de uma conta, de uma aplicação vulnerável ou de outro componente que permita executar código.
O Copy Fail entra como uma segunda etapa: sair de um contexto com poucos privilégios e chegar a um contexto privilegiado.
Por que o AF_ALG é importante
O AF_ALG é uma interface de sockets usada para acessar funcionalidades criptográficas do kernel Linux.
Um programa pode abrir um socket desse tipo e utilizar operações criptográficas sem implementar toda a operação diretamente em userspace.
O fluxo simplificado é:
Aplicação
│
│ AF_ALG
▼
Linux Kernel
│
▼
Subsistema de criptografia
O problema do Copy Fail aparece justamente em um dos caminhos internos utilizados por essa interface.
O código vulnerável está relacionado ao módulo algif_aead.
Um processo sem privilégios que consegue acessar o caminho vulnerável pode explorar o comportamento incorreto da operação de cópia.
O que torna o Copy Fail interessante
À primeira vista, estamos falando de algo relativamente pequeno:
uma operação de cópia
↓
uma página de memória
↓
alguns bytes alterados
Mas essa página pode representar parte de um arquivo que outro processo considera confiável.
Então a cadeia pode se transformar em:
bug no kernel
↓
alteração no page cache
↓
arquivo diferente em memória
↓
outro processo lê o conteúdo alterado
↓
código privilegiado é afetado
↓
escalada de privilégios
Esse é o motivo pelo qual bugs aparentemente pequenos no kernel podem ter consequências grandes.
Como testar
A divulgação pública da vulnerabilidade está em copy.fail.
Para estudar o comportamento, o ideal é utilizar um ambiente de laboratório isolado e descartável, como uma máquina virtual criada especificamente para testes.
Também é importante lembrar que reproduzir o exploit não é necessário para verificar se um sistema está protegido.
A primeira medida deve ser verificar a versão do kernel e instalar as atualizações de segurança disponibilizadas pela distribuição.
Como se proteger
A principal medida é atualizar o kernel Linux para uma versão que contenha a correção da CVE-2026-31431.
Em ambientes Docker, também existem mitigações específicas para impedir que containers alcancem o caminho vulnerável. A Docker disponibilizou correções e recomendações próprias para o problema.
Em outras palavras:
CORREÇÃO
│
▼
Kernel atualizado
│
+
│
MITIGAÇÕES
│
▼
Docker / seccomp /
AppArmor / SELinux
A correção do kernel é a medida principal. As mitigações de isolamento funcionam como uma camada adicional de defesa.
Resumindo
Um processo sem privilégios encontra uma falha no kernel que permite alterar temporariamente, na memória, o conteúdo de um arquivo mantido no page cache.
Se esse arquivo for utilizado por um processo privilegiado, a alteração pode ser transformada em uma escalada de privilégios.
A ideia central é:
AF_ALG
│
▼
bug no kernel
│
▼
alteração no page cache
│
▼
arquivo alterado em RAM
│
▼
processo privilegiado
│
▼
escalação de privilégios
O detalhe mais importante é justamente esse: o atacante não precisa necessariamente alterar o arquivo no disco para alterar aquilo que outro processo lê. O alvo da vulnerabilidade é a cópia que o kernel mantém na memória.
Encontre o Copy Fail nos seus hosts com a runtz
Escaneie todos os seus hosts agora. Comece em runtz.dev.



