Copy Fail – CVE-2026-31431

• Vulnerabilidade de escalonamento de privilégios com escape de contêiner que permite obter privilégios de root em todas as distribuições Linux desde 2017
• Explora uma falha lógica simples presente no módulo de criptografia do kernel Linux (authencesn) e pode ser executada com um único script Python de 732 bytes, sem necessidade de sincronização complexa de tempo (race condition) nem de ajustes por versão do kernel
• O princípio central é a modificação do cache em memória (page cache) que o Linux referencia ao executar arquivos, conectando AF_ALG (socket criptográfico do kernel) e splice() (syscall de cópia de dados) para sobrescrever 4 bytes na cópia em cache de um binário setuid
  • O arquivo real em disco não é alterado, tornando isso um ataque furtivo que não deixa rastros em imagens forenses de disco
  • Após reinicialização ou liberação da memória, o cache volta ao original, o que dificulta a detecção posterior com verificações tradicionais de integridade de arquivos
• Como o page cache é compartilhado por todo o host, em ambientes Kubernetes um único pod pode explorar essa vulnerabilidade para dominar o nó hospedeiro e realizar escape de contêiner alcançando até contêineres de outros tenants
• Verificado diretamente no Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 e SUSE 16, e funciona imediatamente com apenas uma conta local sem privilégios, sem acesso de rede nem recursos de depuração do kernel
• Enquanto vulnerabilidades existentes de escalonamento de privilégios no Linux (LPE) costumam ter taxa de sucesso de 30~80% por tentativa e funcionar apenas em faixas específicas de kernel, o Copy Fail atinge 100% de sucesso em uma única tentativa por 9 anos (2017~2026) em todas as distribuições
• Diferentemente de vulnerabilidades da mesma família de modificação do page cache como Dirty Pipe (abuso de flags de buffer de pipe) e Dirty Cow (exige disputa de timing), ela é muito mais simples e poderosa por não exigir race condition, offsets específicos por distribuição nem recompilação
• Alvos mais urgentes: hosts Linux multi-tenant, clusters Kubernetes/contêineres, runners de CI (GitHub Actions self-hosted, GitLab Runner etc.), SaaS em nuvem que executam código de usuários — qualquer ambiente onde código não confiável roda sobre um kernel compartilhado
• A ação prioritária é aplicar o patch do kernel (commit principal a664bf3d603d) — ele reverte a otimização in-place introduzida no módulo de criptografia em 2017 para impedir que páginas do page cache sejam incluídas como destino de escrita em operações criptográficas
• Como mitigação temporária antes do patch, é possível desativar o módulo algif_aead, sem impacto sobre funcionalidades criptográficas comuns como dm-crypt/LUKS, kTLS, IPsec e SSH
• Em ambientes com workloads não confiáveis, como contêineres, sandboxes e runners de CI, recomenda-se bloquear a criação de sockets AF_ALG via seccomp, independentemente de o patch já ter sido aplicado ou não
• Um caso de detecção de vulnerabilidades assistida por IA: Taeyang Lee, da Xint, teve o insight inicial de que a estrutura em que o splice() entrega páginas do page cache ao subsistema de criptografia representava uma classe de bugs ainda inexplorada, e o Xint Code encontrou a falha ao fazer uma varredura automatizada do subsistema crypto/ do kernel em cerca de uma hora

[popopo]

Parece que o Rocky Linux ainda não tem patch.

RHEL

• https://access.redhat.com/security/cve/cve-2026-31431

AlmaLinux

• https://master.almalinux-org.pages.dev/blog/…

Rocky Linux

• em https://errata.rockylinux.org/ pesquise por 'copy fail', 'cve-2026-31431' etc.
• https://forums.rockylinux.org/t/…

Estou usando Rocky Linux, e se você não puder reiniciar, bloquear com o bpftool de https://github.com/wgnet/wg.copyfail.patch é eficaz.

[popopo]

https://kb.ciq.com/article/rocky-linux/rl-cve-2026-31431-mitigation

Existe um patch, mas ele está disponível apenas no repositório do serviço por assinatura. A versão CE não foi corrigida. (9.7, 10.1 verificados)

[popopo]

O patch saiu em 2026-05-05.

Em 2026-05-10, há uma nova opção de segurança.
https://forums.rockylinux.org/t/…

sudo dnf --enablerepo=security update

Ao adicionar o repositório de segurança, aparentemente é possível aplicar medidas de segurança separadamente da incorporação do código-fonte do RHEL.

[sukso96100]

Quem usa Ubuntu pode consultar o guia com o procedimento de mitigação que foi publicado.

https://discourse.ubuntu.com/t/…

[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