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

[GN⁺]

Comentários no Hacker News

• Do ponto de vista de quem lida com o código de crypto do kernel Linux, esses exploit de AF_ALG que aparecem periodicamente são realmente frustrantes
  O AF_ALG entrou no kernel há muito tempo sem revisão suficiente, a estrutura é complexa demais e ainda abre uma enorme superfície de ataque para programas userspace sem privilégio
  Além disso, é quase desnecessário. O userspace já tem seu próprio código de criptografia, e o código de crypto do kernel foi feito originalmente para usos internos do kernel, como o dm-crypt
  O authencesn deste exploit também é, na prática, um detalhe interno de implementação do IPsec, e expor isso como uma API genérica de criptografia/descriptografia para userspace me parece ter sido um erro desde o início
  Se você administra a configuração do kernel Linux, recomendo fortemente desativar todas as opções CONFIG_CRYPTO_USER_API_*
  Só isso já teria tornado não explorável não apenas este bug, mas também boa parte dos bugs passados e futuros de AF_ALG
  Se algum programa userspace quebrar, o correto é ajudar a migrá-lo para código de crypto em userspace, e de fato isso já aconteceu em alguns casos
  Desde o começo, o AF_ALG nunca teve muita utilidade além de servir para exploits
  Talvez esse tipo de API de userspace fosse mais tolerável no passado, mas com syzbot e detecção de bugs assistida por LLM, está cada vez mais difícil sustentar isso

  • Como eu não sabia o que era AF_ALG, fui procurar e achei https://www.chronox.de/libkcapi/html/ch01s02.html, e lá havia alguns argumentos a favor da sua existência
    Dizem que ele permite usar em userspace aceleradores de hardware acessíveis apenas em modo kernel, passar chaves para o kernel sem deixá-las por muito tempo na memória da aplicação e reduzir o footprint em ambientes com pouca memória, como sistemas embarcados, em comparação com bibliotecas de crypto em userspace
    Não sei dizer se isso é justificativa suficiente, mas pelo menos existe uma razão
  • Fico curioso para saber como isso entrou no kernel
    Como o Linus é conhecido por ser bem exigente com o que entra no kernel, a história por trás da entrada dessa API parece interessante
  • AF_ALG é a interface de socket do Linux que expõe a API de crypto do kernel como descritores de arquivo
    Ela permite tratar hashing e criptografia com chamadas comuns read(2)/write(2)
  • O que mais me deixa curioso é quais softwares quebram se essa opção do kernel for desativada

• Parece ter havido alguma confusão no processo de divulgação
  Os vendors não estão tratando essa vulnerabilidade como algo grave, e por isso várias distribuições ainda seguem sem patch
  Em https://access.redhat.com/security/cve/cve-2026-31431 aparecia "Moderate severity" e "Fix deferred", e as páginas de rastreamento de Debian, Ubuntu e SUSE pareciam semelhantes

  • Desde o momento em que o patch entrou no kernel, isso já estava efetivamente visível para atacantes ou observadores havia semanas
    Mas o upstream não comunicou isso claramente como uma vulnerabilidade, e Linus e Greg conceitualmente não dão tanta importância a esse tipo de classificação no kernel
  • Os motivos para as distribuições tratarem isso como risco médio provavelmente são o fato de não ser execução remota de código, e sim exigir acesso local
    Ainda assim, como permite elevação local para root, no geral parece correto tratá-lo como alta prioridade
    https://ubuntu.com/security/cves/about#priority
  • A RedHat agora mudou para Important severity e Affected
  • Pelas próprias diretrizes da Ubuntu, isso parece que deveria entrar como high priority, mas na prática está marcado como medium, então parece inconsistente

• É uma pena que o texto principal não diga logo de cara quais versões do kernel são vulneráveis e em quais versões isso foi corrigido
  Especialmente porque isso é um módulo builtin, então não dá para remover facilmente com rmmod
  Procurando para confirmar se o kernel 6.19.14 do Fedora 44 era vulnerável, encontrei a postagem da lista linux-cve-announce https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u
  Lá dizia que isso foi corrigido pelos respectivos commits em 6.18.22, 6.19.12 e 7.0, o que ajuda como referência

• Se você quiser verificar se o módulo de kernel algif_aead foi realmente bloqueado via configuração do modprobe, como recomenda a mitigação, não precisa executar aquele shell code ofuscado inteiro
  Dá para confirmar de forma legível, com algumas linhas de Python, se o módulo realmente carrega
  python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
  Se a mitigação foi aplicada corretamente, modprobe algif_aead também deve falhar com erro

• Certamente ninguém está executando agentes de IA totalmente autônomos com permissões de usuário comum em sistemas operacionais afetados
  Combinado com injeção de prompt zero-day, isso pode ser bem desastroso

  • O meu agente já está rodando como root, então nem consigo ver o problema
  • Ainda bem que não transformamos instalar coisas com curl | sh em padrão da indústria

• LPE significa local privilege escalation
  Há abreviações demais na área de segurança e, embora dê para inferir pelo contexto, ainda assim teria sido melhor escrever por extenso na primeira vez

  • LPE é uma sigla bem conhecida dentro da comunidade de segurança, então não acho tão grave que não tenha sido expandida
    Mas concordo que, num texto voltado a um público mais amplo, faz sentido defini-la explicitamente
    Além disso, o texto inteiro parece gerado por IA
  • Em textos para um público amplo, o básico é expandir a sigla antes de usá-la, e os LLMs costumam não seguir muito bem esse tipo de orientação

• Isso foi meio engraçado
  A página dizia que funcionava em RHEL 14.3, mas essa versão nem existe
  O RHEL atual está na série 10.x, então pareceu coisa de quem chegou numa TARDIS

  • 14.3 provavelmente não era a versão do RHEL, mas sim parte da numeração da versão do GCC da Red Hat
    Às vezes aparece algo como gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2), e dá para ver vestígios parecidos nos exemplos abaixo
    https://github.com/anthropics/claude-code/issues/40741
    https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/software-requirements-red-hat-enterprise-linux-10-64-bit.html
  • Na mesma linha também estava 6.12.0-124.45.1.el10_1, e isso é claramente um kernel de RHEL 10
    Esse tipo de erro de digitação é, na verdade, bastante humano
    A pessoa acerta os números longos copiados e colados, mas erra os números simples ao digitá-los à mão
  • Desculpe, isso deve ser corrigido em breve
    Houve uma corrida para reunir informações rapidamente para explicar a questão e, sim, havia também um aspecto de marketing
    Então alguns erros menores acabaram entrando, e agradeço por terem apontado isso
  • Sim, no momento em que vi a frase "Distribuição verificada diretamente: RHEL 14.3", a página de lançamento já me pareceu slop gerado por IA
    https://access.redhat.com/articles/red-hat-enterprise-linux-release-dates
    Depois de ver no fim da página o "Talk to our security experts", até fiquei com a sensação de que o nome desse especialista em segurança talvez fosse Claude

• No RHEL 9/10, algif_aead não era módulo, mas builtin, então não dava para descarregar
  Como alternativa, encontrei uma forma de bloquear AF_ALG via systemd, embora isso exija um drop-in para cada serviço exposto
  Há também um playbook de Ansible cobrindo os casos normalmente mais críticos, sshd e user@
  https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da

  • No RHEL 9/10, também era possível adicionar initcall_blacklist=algif_aead_init aos parâmetros de boot do kernel e reiniciar
    Fazendo isso, o exploit deixou de funcionar
  • Pensei em algo parecido, mas bloquear isso serviço por serviço parece um jogo de whack-a-mole
    Fico pensando em outros caminhos de execução como cronjob e slurmjob, e seria bom haver uma forma de fazer todos os processos herdarem isso no nível do systemd, em vez de configurar cada serviço individualmente

• Esse exploit parece funcionar substituindo um binário SUID para que ele seja executado como PID 0
  Mas o site afirma também permitir fuga de Kubernetes / clusters de contêineres e de CI runners & build farms, sem mostrar uma explicação concreta que sustente a parte de contêineres ou especialmente a fuga de user namespace
  Testei em um Podman rootless e, como esperado, ele não conseguiu escapar do contêiner
  Eles também afirmaram que isso "torna root todas as distribuições Linux lançadas desde 2017", mas na prática só testaram quatro, e no Alpine não funcionou

  • O próprio site disse que mais detalhes vão sair em breve, então talvez as etapas adicionais ou correções venham na parte 2
    Já deixaram o teaser "Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."
  • Essa vulnerabilidade permite sobrescrever bytes de memória de arquivos legíveis, então dá para imaginar vários caminhos de escape em diferentes ambientes
  • A alegação de todas as distribuições desde 2017 parece se basear no fato de a vulnerabilidade ter entrado por um commit do segundo semestre de 2017
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee3
    Mas a explorabilidade real deve variar conforme se trate de um release major recente ou de um kernel de manutenção em branch antiga
  • Esse texto prejudicou bastante a própria credibilidade
    Ainda assim, rodei o PoC diretamente numa instância 24.04 e a vulnerabilidade de fato parece real e suficientemente séria
    Porém, o número de distribuições afetadas parece bem menor do que o alegado, e fica longe da formulação todas as distribuições desde 2017
    Por exemplo, se estou interpretando corretamente, o Ubuntu tem algum impacto até no 16.04 EOL, mas o impacto principal parece estar em kernels de vendor distribuídos mais recentemente, como linux-gcp e linux-oracle-6.7, da linha 6.17
  • Mesmo dentro de um contêiner rootless, se der para chegar a UID 0 real, então a fuga depois pode ser possível
    Só que isso exigiria etapas adicionais, e no Alpine talvez a vulnerabilidade base exista, mas o script só precise de ajustes
    No fim, isso não é um exploit universal pronto para uso, e sim um PoC

• A página em si parece meio vibecoded e tem cara de anúncio, mas a vulnerabilidade é real e o risco parece alto
  Isso explica por que chegou hoje uma grande atualização de segurança, então vou subir a prioridade de atualizar

  • É, isso é um anúncio bem explícito, mas pessoalmente eu não acho um anúncio ruim
    A estrutura é encontrar e corrigir um bug real, fazendo uma contribuição relevante para o ecossistema OSS, e ao mesmo tempo vender a própria ferramenta de segurança
  • Essa turma provavelmente já teria trabalho de sobra mesmo sem anúncio
    Mas também, hoje em dia, quem faz página web toda à mão? Ainda mais sendo desenvolvedor de kernel