Copy Fail – CVE-2026-31431

• Um usuário local sem privilégios pode encadear authencesn, AF_ALG e splice() para obter uma escrita de 4 bytes no page cache de um arquivo legível e, com isso, escalar até privilégios de root
• Funciona em várias distribuições Linux com um único script Python de 732 bytes, sem offsets específicos por kernel nem condições de corrida, e o mesmo exploit pode obter um root shell
• O escopo do impacto abrange a maioria das principais distribuições Linux até a aplicação do patch, e a exposição foi ampla de 2017 até o momento da correção por causa do AF_ALG habilitado na configuração padrão
• Em hosts multi-tenant, clusters Kubernetes / contêineres, runners de CI e Cloud SaaS com execução de código do usuário, uma conta comum ou um único pod pode levar a root no host, então o patch deve ser priorizado
• A resposta principal é aplicar o patch de kernel que inclui o commit da mainline a664bf3d603d; antes disso, é importante desativar algif_aead e bloquear AF_ALG para workloads não confiáveis

---

Visão geral da vulnerabilidade

• Um único defeito lógico linear pode ser encadeado com authencesn, AF_ALG e splice() para chegar a uma escrita de 4 bytes no page cache, permitindo elevação local de privilégios
• Funciona da mesma forma em distribuições Linux lançadas desde 2017 com apenas um script Python de 732 bytes, sem offsets específicos por kernel nem janelas de race
• O mesmo binário de exploit obtém um root shell em várias distribuições sem modificações
• Basta ter uma conta local sem privilégios; não são necessários acesso de rede, recursos de depuração de kernel nem outros primitivos previamente instalados

Escopo do impacto

• A maioria das principais distribuições Linux que usam kernels sem o patch entra no escopo
• Como o AF_ALG da API criptográfica do kernel vem habilitado por padrão em praticamente todas as distribuições mainstream, a exposição foi imediata de 2017 até o momento do patch
• As distribuições verificadas diretamente foram Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 14.3 e SUSE 16
• Debian, Arch, Fedora, Rocky, Alma, Oracle e linhagens embarcadas também são afetadas se usarem kernels vulneráveis

Ambientes que precisam de patch prioritário

• Em hosts Linux multi-tenant, vários usuários compartilham o mesmo kernel, então uma conta de usuário arbitrária pode virar root imediatamente
• Em clusters Kubernetes / contêineres, o page cache é compartilhado por todo o host, então um único pod pode comprometer o nó e ultrapassar as fronteiras entre tenants
• Em runners de CI e build farms, código de PR não confiável executado com permissões de usuário comum pode virar root no runner
• Em Cloud SaaS com execução de código do usuário, contêineres ou scripts enviados por tenants podem levar a root no host
• Servidores single-tenant têm um perfil mais de LPE interna e podem ser combinados com RCE web ou credenciais comprometidas
• Notebooks e workstations de usuário único têm urgência menor, mas execução local de código ainda pode levar diretamente a elevação para root

PoC pública e modo de uso

• A PoC foi publicada para que equipes de defesa possam validar sistemas e confirmar patches de fornecedores
• copy_fail_exp.py usa apenas as bibliotecas padrão do Python 3.10+ os, socket e zlib
• O alvo padrão é /usr/bin/su, mas outro binário setuid pode ser passado em argv[1]
• O exploit modifica um binário setuid no page cache; a mudança não persiste após reboot, mas o root shell obtido funciona de fato
• Issue tracker

Mitigação

• A prioridade é aplicar o patch de kernel e atualizar para um kernel de distribuição que inclua o commit de mainline a664bf3d603d
• Esse patch reverte a otimização in-place do algif_aead, introduzida em 2017, para impedir que páginas do page cache entrem na scatterlist de destino gravável
• Antes do patch, recomenda-se desativar o módulo algif_aead
  • echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
  • rmmod algif_aead 2>/dev/null || true
• Em contêineres, sandboxes e ambientes de CI que executam workloads não confiáveis, é necessário bloquear a criação de sockets AF_ALG com seccomp, independentemente do status do patch

Impacto ao desativar

• Na maioria dos sistemas, há pouco ou nenhum impacto mensurável
• dm-crypt / LUKS, kTLS, IPsec/XFRM, TLS in-kernel, builds padrão de OpenSSL/GnuTLS/NSS, SSH e a crypto do keyring do kernel não são afetados
  • Eles usam a API criptográfica do kernel diretamente e não passam pelo caminho AF_ALG
• Se o engine afalg estiver explicitamente habilitado no OpenSSL, alguns caminhos de offload criptográfico embarcado e aplicações que fazem bind direto em sockets aead/skcipher/hash podem ser afetados
  • É possível verificar com lsof | grep AF_ALG ou ss -xa
• Desabilitar AF_ALG não deixa mais lento o que já não o utilizava; os casos que o usavam voltam para bibliotecas de criptografia usuais em userspace

O que diferencia de um Linux LPE comum

• Diferentemente de um LPE comum em Linux, não há condição de corrida e não são necessários offsets por distribuição
• A confiabilidade é apresentada como 100% em uma única tentativa, cobrindo um período longo de 2017 a 2026, e não uma faixa estreita de versões de kernel
• Com apenas 732 bytes e usando só a biblioteca padrão do Python, não há payload compilado nem dependências extras
• O caminho de escrita contorna o VFS e a página corrompida não é marcada como dirty, então nada é gravado em disco
• Como o page cache é compartilhado por todo o host, ele funciona não só como LPE simples, mas também como primitivo de escape de contêiner

Princípio de funcionamento e características de detecção

• Um usuário local sem privilégios pode escrever 4 bytes controláveis no page cache de um arquivo legível em um sistema Linux e usar isso para obter root
• O alvo não é o arquivo real em disco, mas o page cache em memória; ao alterar a cópia em cache de /usr/bin/su, do ponto de vista do execve é como alterar o próprio binário
• Como não há mudança em disco, o inotify não dispara, e após reboot ou expulsão do cache o arquivo original é recarregado
• Ferramentas de hash comuns como sha256sum, AIDE e Tripwire leem o page cache via read(), então enquanto a corrupção permanecer em cache o hash pode divergir do valor de referência
• Quando o cache é expulso ou o sistema reinicia, o hash volta a coincidir com o original, e imagens forenses do disco mostram apenas o arquivo não modificado
• No modo enforcing de IMA appraisal, se a medição em toda leitura estiver ativada, o binário corrompido pode ser detectado no momento do execve, antes de ser executado

Diferenças para outras vulnerabilidades

• É da mesma família de Dirty Pipe, pois corrompe o page cache a partir de userspace sem privilégios e obtém root ao escrever em um binário setuid sem alterar o disco
• O mecanismo é diferente: Dirty Pipe explorava flags de pipe buffer, enquanto Copy Fail explora uma AEAD scratch write que cruza fronteiras de scatterlist encadeadas
• Dirty Pipe exigia kernel 5.8+ com um patch específico; Copy Fail cobre a janela de 2017 a 2026
• Diferentemente de Dirty Cow, não é preciso vencer uma corrida COW baseada em TOCTOU, repetir várias tentativas ou desestabilizar o sistema

Detalhes adicionais

• /usr/bin/su não é obrigatório; qualquer binário setuid-root legível pelo usuário pode servir, como passwd, chsh, chfn, mount, sudo ou pkexec
• Não é uma vulnerabilidade remota; primeiro é necessário execução local de código com privilégios de usuário comum
• Se um RCE web cair em uma conta de serviço sem privilégios, ele pode ser combinado com um foothold por SSH, um PR malicioso em runner de CI ou vetores semelhantes para chegar a root
• O patch reverte a otimização in-place do algif_aead, fazendo req->src e req->dst voltarem a usar scatterlists separadas
• As páginas do page cache permanecem apenas na source somente leitura, e o único destino gravável pela operação criptográfica passa a ser o buffer do usuário

Cronograma de divulgação e materiais adicionais

• Reportado à equipe de segurança do kernel Linux em 2026-03-23
• Confirmação inicial realizada em 2026-03-24
• Patch proposto e revisado em 2026-03-25
• Patch commitado na mainline em 2026-04-01
• CVE-2026-31431 atribuído em 2026-04-22
• Divulgado em https://copy.fail/ em 2026-04-29
• Análise técnica no blog da Xint
  • Inclui root cause, diagrama de scatterlist, histórico 2011→2015→2017 e walkthrough do exploit
  • A Parte 2, sobre escape de contêiner em Kubernetes, está prevista para publicação futura

Informações relacionadas à Xint Code

• Foi encontrado de forma assistida por IA, e o ponto de partida foi uma pesquisa humana sobre o fato de splice() passar páginas do page cache ao subsistema de crypto e sobre a possibilidade de a origem das páginas em scatterlists ser uma classe de bug pouco explorada
• Depois disso, a Xint Code expandiu a auditoria para todo o subsistema crypto/ do Linux em aproximadamente 1 hora, e o item mais grave entre os resultados foi o Copy Fail
• Xint Code
  • Write-up no blog da Xint
  • Outros bugs de alto risco também foram encontrados no mesmo scan e ainda estão em processo de divulgação coordenada