Quando a vulnerabilidade CVE-2026-31431, apelidada de “Copy Fail”, foi divulgada no final de abril, muita gente tratou o problema como “o novo Dirty Pipe”. A comparação faz sentido, mas também simplifica demais o que aconteceu.
O Copy Fail não é apenas mais uma falha de escalonamento de privilégios no kernel Linux. Ele é um exemplo raro de bug lógico extremamente confiável, portátil entre distribuições e sem depender de condições normalmente necessárias para explorar vulnerabilidades de kernel, como race conditions, offsets específicos ou corrupção imprevisível de memória.
O mesmo exploit de 732 bytes funciona em Ubuntu, RHEL, SUSE, Amazon Linux e praticamente qualquer distribuição Linux moderna lançada desde 2017.
O que exatamente é o Copy Fail?
O Copy Fail é uma vulnerabilidade de escalonamento local de privilégios (LPE — Local Privilege Escalation) presente no subsistema criptográfico do kernel Linux. Ela recebeu o identificador CVE-2026-31431 e afeta o módulo algif_aead, parte da interface AF_ALG do kernel.
Traduzindo isso para algo mais humano: O Linux possui uma API interna que permite que programas no espaço de usuário utilizem diretamente funções criptográficas do kernel através de sockets especiais. Essa interface é o AF_ALG.
Ela é utilizada principalmente para acelerar operações criptográficas ou integrar criptografia em aplicações específicas.
O problema é que uma otimização introduzida em 2017 criou um cenário em que páginas do page cache do kernel podem acabar sendo reutilizadas de maneira incorreta durante operações de criptografia AEAD.
E aí entra o ponto crítico: um usuário comum consegue escrever alguns bytes controlados dentro do cache de um arquivo protegido do sistema, mesmo sem permissão para editar esse arquivo.
O que é o page cache?
Essa parte é essencial para entender a gravidade do problema. O Linux mantém arquivos frequentemente acessados em memória RAM por meio do chamado page cache.
Isso significa que, quando um programa lê /usr/bin/su, por exemplo, o conteúdo desse arquivo provavelmente já está carregado em memória. E o page cache é compartilhado.
Ou seja:
- containers compartilham;
- processos compartilham;
- usuários compartilham;
- o host compartilha.
Se alguém consegue modificar dados dentro desse cache, consegue alterar temporariamente o comportamento de binários importantes do sistema, mesmo que o arquivo no disco permaneça intacto. Foi exatamente isso que tornou o Dirty Pipe tão perigoso em 2022 e o Copy Fail segue uma lógica parecida.
O papel do splice()
A exploração utiliza uma syscall chamada splice(). Ela existe para mover dados entre arquivos e sockets sem precisar copiá-los manualmente para o espaço de usuário, o que melhora bastante o desempenho. Só que o splice() trabalha diretamente com buffers do kernel.
E o bug do Copy Fail permite que buffers ligados ao page cache acabem sendo tratados como destinos graváveis durante uma operação criptográfica, seguindo o seguinte fluxo:
- O atacante abre um arquivo somente leitura;
- Usa splice() para conectar esse arquivo ao socket AF_ALG;
- O kernel reutiliza páginas do page cache de forma incorreta;
- O atacante escreve alguns bytes dentro do cache do arquivo protegido;
- Um binário SUID acaba executando código adulterado;
- O usuário vira root.
Tudo isso sem race condition, independentemente do timing, sem offsets específicos do kernel, ASLR bypass ou alguma corrupção caótica de memória. É quase uma “linha reta” até o root.
Por que ele funciona em praticamente qualquer distro?
A maioria dos exploits de kernel precisa ser adaptada para cada distribuição. O motivo vai desde versões diferentes do kernel, offsets diferentes, proteções diferentes, até mesmo layouts diferentes no uso da memória.
Mas o Copy Fail não depende disso; ele explora a lógica do kernel, não detalhes específicos de implementação. Segundo os pesquisadores da Theori, o mesmo script funciona sem modificações em kernels lançados desde 2017.
Destrinchando o exploit
O código divulgado é pequeno, mas bastante inteligente.
Logo no início temos:
a=s.socket(38,5,0) a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"))Aqui o exploit cria um socket AF_ALG usando um algoritmo criptográfico AEAD.
Depois:
u.sendmsg(...)Essa chamada envia mensagens manipuladas para o socket criptográfico. É aqui que o kernel prepara internamente os scatterlists — estruturas usadas para mapear buffers de memória.
Então aparece a parte crítica:
n(f,w,o,offset_src=0) n(r,u.fileno(),o)Aqui o splice() move dados diretamente entre:
- o arquivo alvo;
- pipes internos;
- o socket AF_ALG.
Esse fluxo faz o kernel reutilizar páginas do page cache como destino gravável. E então o exploit escreve apenas 4 bytes por vez dentro do cache de /usr/bin/su.
Por que apenas 4 bytes bastam?
Porque o objetivo não é sobrescrever o binário inteiro. O exploit altera pequenos trechos cuidadosamente escolhidos para modificar o fluxo de execução do programa SUID.
Depois disso:
g.system("su")O atacante simplesmente executa su, só que agora o binário em memória já foi adulterado.
O resultado é:
uid=0(root)Containers são o verdadeiro problema
No desktop Linux, o risco é relativamente limitado, pois ainda é necessário executar código localmente, dependendo de baixar algo malicioso, executar um binário comprometido e rodar código não confiável.
Mas em ambientes corporativos, o cenário muda completamente.
Especialmente em:
- clusters Kubernetes;
- runners de CI/CD;
- plataformas SaaS;
- sandboxes de IA;
- ambientes multi-tenant.
Nesses cenários, usuários diferentes compartilham o mesmo kernel e o page cache também. Isso transforma o Copy Fail num potencial escape de container extremamente perigoso.
O que muda daqui pra frente
Talvez o aspecto mais importante do Copy Fail nem seja a falha em si. Segundo a Theori, ela foi encontrada por um sistema de IA chamado Xint Code em aproximadamente uma hora e isso chamou a atenção da indústria inteira, afinal, agora falhas profundas de lógica parecem estar ficando muito mais baratas de descobrir.
Isso pode mudar completamente a dinâmica de segurança do kernel Linux nos próximos anos. O Copy Fail talvez seja menos lembrado como “aquele bug do AF_ALG” e mais como um sinal de que a era dos exploits raros e extremamente caros pode estar começando a mudar.
Contribua para o Diolinux seguir crescente e independente: seja membro Diolinux Play e tenha acesso a conteúdos e outros benefícios exclusivos!