Por que o “Copy Fail” é diferente das vulnerabilidades anteriores do kernel do Linux

Vá direto para um resumo gerado por IA desta postagem do blog

A versão resumida

O que: Uma vulnerabilidade de escalonamento de privilégios locais no Linux chamada Copy Fail (CVE-2026-31431), uma falha lógica no caminho AEAD de autenticação do kernel, acessível a partir do espaço do usuário por meio da interface de soquete AF_ALG e da função splice(2).

Impacto: Uma prova de conceito publicada, com 732 bytes, é capaz de elevar de forma confiável um usuário local sem privilégios ao nível de root nas principais distribuições Linux que executam kernels vulneráveis.

Status: Kernels corrigidos já estão sendo distribuídos pelo AlmaLinux, Ubuntu e outros projetos derivados. A CISA adicionou o CVE-2026-31431 ao seu catálogo de vulnerabilidades conhecidas como exploradas em 1º de maio. CVSS 7,8 (ALTA).

Gravidade: Vetor local, sem necessidade de privilégios, sem interação do usuário, exploração altamente confiável. Em muitos ambientes de contêineres ou de execução compartilhada, uma exploração bem-sucedida a partir de um contêiner pode levar ao comprometimento do host.

Faça isso agora: proteja os kernels afetados imediatamente. As organizações que utilizam a aplicação de patches em tempo real sem reinicialização podem neutralizar a vulnerabilidade sem esperar por janelas de manutenção ou reinicializações. Caso contrário, implante kernels corrigidos pelo fornecedor assim que for operacionalmente possível. Se nenhuma dessas opções for viável imediatamente, desative temporariamente a rota AF_ALG AEAD vulnerável seguindo as orientações de mitigação abaixo.

O Copy Fail é importante porque combina três características que os defensores não gostam de ver juntas: amplo alcance de distribuição, exploração altamente confiável e uma prova de conceito pública divulgada no mesmo dia da revelação.

Isso me afeta?

É quase certo que sim, a menos que você já tenha instalado a atualização.

A falha “Copy Fail” afeta o Linux upstream a partir do kernel 4.14, o que significa que praticamente todas as distribuições corporativas com manutenção ativa herdaram o caminho de código vulnerável:

Versões do Ubuntu anteriores à Resolute (26.04)
Red Hat Enterprise Linux 8, 9 e 10
AlmaLinux 8, 9, 10 e Kitten 10
Equivalentes do Rocky Linux, do CentOS Stream e do Oracle Linux
Fedora (atual e versões recentes)
Debian estável e testing
openSUSE Tumbleweed e Leap
A maioria das compilações derivadas, incluindo as variantes do CloudLinux

A maior preocupação é a população de dispositivos fora das frotas corporativas mantidas ativamente: aparelhos com Linux embarcado, kernels OEM em equipamentos de rede, sistemas industriais e implantações em fim de vida útil que talvez nunca recebam uma correção. Se um dispositivo não tiver recebido atualizações do kernel do fornecedor recentemente, considere que ele pode permanecer permanentemente exposto.

A vulnerabilidade depende de o kernel expor o algif_aead, que é configurado de uma das duas maneiras, dependendo da distribuição.

Verificação rápida:


# Check if loaded as a module (Debian, Ubuntu, Arch-family)

lsmod | grep '^algif_aead '

# Check if built into the kernel (RHEL, AlmaLinux, Rocky, CentOS Stream, Oracle, CloudLinux)

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Uma saída vazia do `lsmod` não é o sinal de segurança que parece ser. No Debian, no Ubuntu e nas distribuições da família Arch, o `algif_aead` é carregado automaticamente sob demanda — um processo sem privilégios pode acionar o carregamento simplesmente abrindo um soquete `AF_ALG` com um nome de algoritmo correspondente. Nas distribuições da família RHEL, o código é compilado diretamente no kernel (CONFIG_CRYPTO_USER_API_AEAD=y) e nunca aparece no `lsmod`, independentemente do estado. Considere o host como vulnerável, a menos que a linha de comando do kernel coloque explicitamente a chamada de inicialização AEAD na lista negra ou que o kernel tenha sido corrigido.

Você também não está protegido simplesmente porque sua distribuição reforça a segurança dos espaços de nomes do usuário. O gatilho “Copy Fail” não exige a criação de um novo espaço de nomes — a família de soquetes AF_ALG pode ser acessada diretamente por um processo padrão sem privilégios em instalações padrão.

O que é uma falha de redação

O “Copy Fail” é uma vulnerabilidade de escalonamento de privilégios local no subsistema de criptografia do kernel do Linux. O bug está presente no modelo AEAD “authencesn” — o modo de criptografia autenticada utilizado para o ESN do IPsec — e pode ser explorado quando acessado por meio do AF_ALG em conjunto com a função splice(2).

A combinação vulnerável surgiu de três alterações realizadas com anos de intervalo entre si, nenhuma das quais era incorreta por si só. O modelo `authencesn`, adicionado em 2011 para lidar com os Números de Sequência Estendidos do IPsec ESP, utilizava o buffer de destino do chamador como espaço temporário — o que era inofensivo quando apenas a camada interna `xfrm` do kernel o chamava. Posteriormente, o AF_ALG expôs as operações AEAD ao espaço do usuário. Em 2017, uma otimização de desempenho removeu uma cópia interna no caminho AEAD, permitindo que o kernel operasse diretamente na página de memória fornecida. A combinação tornou-se perigosa quando o caminho de dados se originou da função `splice(2)` em relação a uma página do cache de páginas respaldada por arquivo.

A própria descoberta é parte do motivo pelo qual essa falha é importante. O pesquisador da Theori, Taeyang Lee, levantou a hipótese de que a combinação de soquetes AF_ALG com a função splice(2) poderia criar uma superfície de ataque pouco explorada em torno da proveniência das páginas da lista de dispersão. Em vez de realizar uma auditoria manualmente, a equipe inseriu essa hipótese de uma linha no Xint Code — seu sistema de varredura assistido por IA —, direcionado ao diretório crypto/. Cerca de uma hora depois, o “Copy Fail” apareceu como a descoberta de maior gravidade. Outros bugs de alta gravidade identificados na mesma varredura ainda estão sendo tratados por meio de um processo de divulgação coordenada.

A correção no upstream consiste na reversão direta do commit original da otimização (a664bf3d603d). Esse detalhe é importante porque ilustra como esses bugs costumam passar despercebidos na revisão: a otimização em si parecia correta quando analisada isoladamente, mas os caminhos de execução adjacentes nunca foram modelados em relação a ela.

Por que o “Copy Fail” é diferente

Essa é a parte que merece atenção se você acompanhou o fluxo constante de LPEs do Linux na última década – Dirty COW, Dirty Pipe, StackRot, Dirty Frag e outras da mesma família.

O “Dirty Pipe” foi importante porque transformou a corrupção do cache de páginas em uma primitiva prática de escalonamento de privilégios. A maioria dos bugs dessa categoria, no entanto, ainda apresentava atritos operacionais. Eles envolviam condições de corrida, eram específicos a versões do kernel, dependiam de módulos incomuns, eram bloqueados por restrições de namespace ou eram pouco confiáveis o suficiente para que os defensores pudessem, de forma realista, ganhar tempo.

O Copy Fail elimina grande parte desse atrito.

Segundo relatos, o exploit publicado funciona com pouca ou nenhuma modificação nas principais distribuições Linux convencionais testadas pelos pesquisadores. Não há uma tabela de deslocamento extensa por distribuição nem uma lógica demorada de seleção de alvos. O caminho do exploit é excepcionalmente portátil.

A janela de exposição também é excepcionalmente ampla. A otimização vulnerável foi incorporada ao Linux upstream em 2017 e se propagou para kernels com suporte de longo prazo que ainda hoje permanecem dentro das janelas de suporte dos fornecedores. Isso inclui sistemas corporativos, implantações embarcadas, dispositivos especializados e infraestruturas congeladas, cuja atualização as organizações costumam adiar por anos.

Acima de tudo, a exploração é altamente confiável. Muitas LPEs modernas do kernel envolvem comportamento probabilístico — modelagem de heap, medição de tempo de corrida ou cadeias complexas envolvendo múltiplas primitivas. O “Copy Fail” é comparativamente simples. As tentativas são bem-sucedidas ou falham de forma clara, sem desestabilizar o host.

A superfície de ataque acessível também é excepcionalmente comum. Ao contrário dos módulos de nicho envolvidos em algumas explorações recentes do kernel, o algif_aead é amplamente distribuído nas principais distribuições e é compilado por padrão ou carregado automaticamente quando solicitado. As instalações padrão em servidores, desktops e hosts de contêineres frequentemente expõem um caminho acessível a partir de um processo sem privilégios até o código vulnerável.

O resultado é que muitas das suposições tradicionais de “ganhar tempo” não ajudam muito nesse caso. Na prática, uma redução significativa do risco se resume a aplicar patches no kernel ou bloquear o acesso ao caminho vulnerável.

Por que a infraestrutura moderna agrava essa situação

O termo “invasor local” costumava indicar algo relativamente restrito — acesso físico, uma credencial SSH roubada ou um comprometimento prévio da rede.

Essa definição já não reflete mais como a infraestrutura do Linux funciona em 2026.

A infraestrutura moderna é construída com base na execução compartilhada. Os nós do Kubernetes hospedam conjuntamente cargas de trabalho de diferentes namespaces. Os executores de CI/CD executam o código de pull requests de colaboradores externos. Notebooks na nuvem, ambientes de teste para desenvolvedores, plataformas SaaS multilocatárias e sistemas de compilação executam rotineiramente código parcialmente confiável em kernels compartilhados.

Nesse contexto, o termo “local” se assemelha cada vez mais ao que “conectado à internet” costumava significar.

Uma dependência maliciosa do npm que chega à integração contínua (CI), uma vulnerabilidade de execução de código remoto (RCE) em um aplicativo web que concede um shell com privilégios baixos, uma conta de desenvolvedor comprometida ou uma cadeia incompleta de fuga de contêiner podem se tornar pontos de apoio para o acesso total como root. O Copy Fail reduz a distância entre o ponto de entrada inicial e o comprometimento total no nível do kernel.

A vulnerabilidade, por si só, não pode ser explorada remotamente. Um invasor ainda precisa de execução de código em algum ponto do host. Mas, em ambientes de execução compartilhada, a oferta de pontos de entrada potenciais já é grande o suficiente para que essa distinção tenha menos importância do que antes.

Como a vulnerabilidade realmente funciona

O Linux disponibiliza as funcionalidades de criptografia do kernel ao espaço do usuário por meio dos soquetes AF_ALG. Um processo pode solicitar algoritmos como authencesn(hmac(sha256),cbc(aes)) e transmitir dados por meio de interfaces padrão de leitura/gravação.

A otimização de 2017 teve como objetivo melhorar o desempenho, evitando cópias internas desnecessárias durante certas operações AEAD. Em vez de copiar os dados de entrada para buffers temporários e copiar os resultados de volta, o kernel podia, em alguns casos, operar diretamente na página de memória fornecida.

Essa suposição deixa de se aplicar quando a entrada provém, por meio da função `splice(2)`, de um descritor associado a um arquivo. Ao contrário das operações comuns de leitura e gravação, a função `splice` pode transferir referências a páginas já armazenadas em cache, em vez de copiar os dados. O caminho de criptografia tratou incorretamente essas páginas como espaço temporário gravável e realizou uma transformação no próprio local sobre elas.

Esse comportamento é específico do authencesn. Outros algoritmos AEAD padrão — GCM, CCM, authenc comum — restringem suas gravações à área de saída legítima. O modelo authencesn, originalmente escrito para um caminho de código IPsec interno que controlava ambas as extremidades da operação, trata a lista de dispersão de destino do chamador como espaço temporário. Quando o AF_ALG expôs esse caminho ao espaço do usuário e o splice injetou páginas respaldadas por arquivos nele, o resultado foi uma primitiva que grava 4 bytes controlados por operação no cache de páginas de qualquer arquivo legível.

Na verdade, cada operação falha — a verificação HMAC falha porque o texto cifrado é falso, e a função recvmsg() retorna um erro ao chamador. A gravação de 4 bytes ocorre de qualquer maneira. Ao repetir a operação em deslocamentos selecionados, um invasor insere um shellcode na imagem armazenada em cache de um binário setuid, como o /usr/bin/su.

O conteúdo do disco nunca muda. A modificação permanece apenas na memória até que a página armazenada em cache seja removida. Ferramentas de integridade do sistema de arquivos, hash de arquivos e análise forense de disco podem, portanto, não detectar nada de anormal, mesmo que a imagem executável armazenada em cache tenha sido alterada por tempo suficiente para que o invasor a execute como root.

A cadeia de prova de conceito (PoC) pública segue uma cadeia relativamente curta:

Abrir um soquete AF_ALG vinculado a authencesn
Abrir um binário com permissão setuid, como /usr/bin/su, para leitura
Use o comando `splice` para mover as páginas armazenadas em cache do alvo para o caminho AF_ALG
Acionar a operação de criptografia in-place, que grava 4 bytes escolhidos pelo invasor a cada chamada
Repita o processo em todos os deslocamentos para inserir o shellcode na imagem armazenada em cache
Execute o binário em cache modificado como root

Já existem reimplementações em C, Go e na arquitetura arm64, além do PoC original em Python. O fato de o Python na plataforma-alvo ser uma versão mais antiga não representa um obstáculo significativo. O artigo original do Xint/Theori continua sendo a melhor referência técnica para defensores que precisam de detalhes mais aprofundados sobre a implementação.

Mitigação

A medida de correção mais segura é proteger imediatamente o kernel em execução. Existem três maneiras práticas de reduzir a exposição, listadas aqui em ordem de rapidez e impacto operacional.

1. Aplicação de patches sem reinicialização (mais rápida, sem tempo de inatividade)

A KernelCare lançou patches em tempo real para o “Copy Fail” destinados aos kernels corporativos em execução compatíveis, antes que várias distribuições derivadas lançassem versões atualizadas dos pacotes do kernel.

O patch que dispensa a reinicialização neutraliza a vulnerabilidade no kernel em execução sem exigir uma reinicialização imediata – reduzindo a exposição de imediato, em vez de esperar pelo próximo ciclo de manutenção.

Alguns verificadores de vulnerabilidades podem continuar, temporariamente, a sinalizar versões do kernel afetadas mesmo após a aplicação de patches sem reinicialização, pois as versões dos pacotes dos fornecedores e a lógica de detecção dos verificadores podem ficar desatualizadas em relação ao estado atual do kernel em execução protegido.

Para organizações que gerenciam infraestruturas em que o tempo de atividade é fundamental, esse é o caminho mais rápido para a correção do problema.

Ainda não é cliente da KernelCare? Os preços para novos clientes têm desconto até o final de junho. Saiba mais sobre a KernelCare aqui.

2. Instale um kernel corrigido e reinicie o sistema

O procedimento padrão de correção consiste em instalar o pacote do kernel corrigido fornecido pelo fornecedor e reiniciar os sistemas afetados.

As organizações devem verificar a disponibilidade de patches para sua distribuição e priorizar os ambientes nos quais código parcialmente confiável pode ser executado — incluindo nós do Kubernetes, executores de CI/CD, servidores compartilhados, infraestrutura de desenvolvedores e plataformas de aplicativos multilocatárias.

3. Mitigação manual temporária (caso a aplicação do patch tenha que ser adiada)

Caso não haja janelas disponíveis para correções dinâmicas nem para reinicialização imediata, a superfície de ataque do AF_ALG AEAD pode ser temporariamente desativada por meio da linha de comando do kernel.

Leia isto primeiro: as medidas de mitigação abaixo eliminam a superfície de ataque do AF_ALG AEAD. A maioria das cargas de trabalho apresenta uma degradação gradual do desempenho – dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS e SSH não dependem disso. Aplicativos que utilizam explicitamente o mecanismo afalg do OpenSSL, o descarregamento de criptografia por hardware via AF_ALG ou a ligação direta de soquetes AEAD podem apresentar falhas ou perda de desempenho. Verifique antes de uma implantação em larga escala.

Primeiro, verifique como o algif_aead é fornecido no seu kernel:

# Loadable module (Debian, Ubuntu, Arch family)

grep -qE '^algif_aead ' /proc/modules && echo "loaded as module" || echo "not currently loaded"

# Built-in (RHEL, AlmaLinux, Rocky, CentOS Stream, Oracle Linux, CloudLinux)

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Se o comando `grep` na configuração retornar `=y`, o código será compilado no kernel. As listas de bloqueio do `modprobe` e o `rmmod` parecerão ter sido executados com sucesso, sem exibir nenhuma mensagem, mas não oferecerão proteção alguma.

Mitigação universal (funciona tanto em kernels de módulo quanto nos integrados) – desative o initcall por meio da linha de comando do kernel:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

sudo reboot

Após a reinicialização, verifique:

grep -o 'initcall_blacklist=algif_aead_init' /proc/cmdline

Uma saída vazia significa que o parâmetro não foi aceito — verifique novamente o grubby e confirme se realmente ocorreu uma reinicialização.

Mitigação exclusiva para módulos carregáveis (Debian, Ubuntu, Arch e similares) – útil quando é necessário adiar a reinicialização:

sudo sh -c 'echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif_aead.conf'

sudo rmmod algif_aead 2>/dev/null || true

Confirmar:

grep -qE '^algif_aead ' /proc/modules && echo "still loaded" || echo "not loaded"

Não confie nessa abordagem em máquinas da família RHEL. Ambos os comandos retornam sucesso independentemente de o sistema estar integrado, o que gera uma falsa sensação de proteção.

Se houver suspeita de exploração, esvazie o cache de páginas para que as páginas executáveis modificadas sejam recarregadas do disco:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Isso é contenção, não remediação. Se um invasor já obteve acesso de root, pode ser que já existam mecanismos de persistência em outras partes do sistema.

O SELinux e o AppArmor podem, tecnicamente, bloquear a criação de soquetes AF_ALG, mas apenas quando configurados para negá-la a processos sem restrições ou com permissão ampla. As políticas padrão em todas as principais distribuições permitem essa criação. Considere a restrição baseada em MAC como uma medida de fortalecimento de segurança para implantações em toda a frota, e não como uma mitigação a ser aplicada no mesmo dia.

Para os operadores do Kubernetes, a OVHcloud publicou uma abordagem de mitigação do DaemonSet para clusters gerenciados. Esse mesmo padrão pode ser aplicado de maneira ampla em ambientes do Kubernetes nos quais é difícil coordenar reinicializações durante janelas de resposta a emergências.

Se o AF_ALG não puder ser desativado porque as cargas de trabalho dependem dele, as opções restantes são isolar a execução local não confiável ou aplicar correções no kernel sem reinicialização até que haja janelas de manutenção disponíveis.

Para os usuários do KernelCare Enterprise, foram lançados patches que corrigem a falha “Copy Fail” sem a necessidade de reinicialização para os kernels empresariais já suportados, antes que várias distribuições derivadas publicassem versões atualizadas dos pacotes do kernel.

Como resultado, alguns scanners podem continuar temporariamente a sinalizar versões vulneráveis do kernel, mesmo quando o kernel em execução já tiver sido protegido por meio de correções sem reinicialização. Espera-se que sejam disponibilizadas versões atualizadas do kernel pelos fornecedores, bem como a lógica de detecção correspondente.

Detecção

Não existe uma assinatura confiável de detecção pós-compromisso para o “Copy Fail”.

Uma exploração bem-sucedida não deixa nenhum vestígio no disco, o padrão das chamadas de sistema se assemelha à atividade legítima de criptografia no espaço do usuário e as modificações armazenadas em cache desaparecem assim que as páginas são removidas.

Na maioria dos ambientes, a confirmação retrospectiva será difícil, a menos que a telemetria de chamadas de sistema, a instrumentação eBPF ou o registro detalhado de auditoria já estivessem habilitados antes da ocorrência da exploração.

Os sinais mais úteis a serem monitorados incluem:

Carregamento inesperado do módulo algif_aead em sistemas sem consumidores conhecidos de AF_ALG
Execução incomum do comando `su` ou `sudo` logo após atividade do AF_ALG
Operações `splice(2)` direcionadas a soquetes AF_ALG a partir de descritores baseados em arquivos

Regras de detecção baseadas em padrões de execução do Python não identificarão outras implementações – as reimplementações da vulnerabilidade em C, Go e arm64 são públicas e não requerem o Python no sistema alvo. Trata-se de heurísticas, não de garantias. Qualquer sistema em que usuários não confiáveis tenham tido acesso ao shell durante o período de exposição deve ser considerado potencialmente comprometido.

Lista de verificação de medidas corretivas priorizadas

Aplique um patch que não exija reinicialização ou implante um kernel corrigido imediatamente. Os usuários do KernelCare Enterprise podem neutralizar a vulnerabilidade em kernels em execução compatíveis sem precisar reiniciar o sistema. Caso contrário, instale o pacote do kernel corrigido pelo fabricante e reinicie os sistemas afetados.
Caso seja necessário adiar a aplicação da correção, aplique a medida de mitigação por linha de comando do kernel `initcall_blacklist=algif_aead_init` após avaliar o impacto na carga de trabalho. A solução alternativa baseada em `modprobe`, divulgada em alguns alertas iniciais, não funciona em kernels da família RHEL.
Analise os ambientes nos quais código parcialmente confiável pode ser executado – sistemas de CI, servidores compartilhados, nós do Kubernetes, infraestrutura de desenvolvedores e conjuntos de instâncias de trabalho em SaaS.
Fique atento a atividades suspeitas relacionadas ao AF_ALG a partir da divulgação, em 29 de abril, e nos dias seguintes.
Reinicie os sistemas corrigidos para limpar o estado de execução vulnerável e as páginas em cache.

Por que esse tipo de inseto continua voltando?

Copy Fail, Dirty Pipe e Dirty Frag diferem em detalhes de implementação, mas compartilham o mesmo padrão subjacente: caminhos rápidos orientados para o desempenho que fazem suposições incorretas sobre a propriedade da memória.

Em cada caso, uma operação de gravação atingiu uma página que o kernel considerou, erroneamente, segura para modificação.

O cache de páginas acaba sendo alvo de ataques repetidamente porque é compartilhado intencionalmente. Todo processo que lê um arquivo acessa a mesma página física subjacente. Uma única gravação acidental nessa página compartilhada pode se tornar visível para binários com privilégios que carregam código executável a partir dela.

A solução não é simplesmente “parar de otimizar”. Os sistemas modernos dependem desses caminhos de desempenho. Desativar permanentemente o módulo que por acaso esteve envolvido na última exploração também não é uma solução de longo prazo.

A solução mais abrangente envolve garantir com maior rigor a propriedade das páginas em todas as rotas de gerenciamento de memória do kernel — um trabalho que os mantenedores do upstream já iniciaram, mas que avança lentamente porque afeta alguns dos subsistemas do kernel mais sensíveis ao desempenho.

É provável que o “Copy Fail” não seja a última vulnerabilidade dessa família.

E o Linux pode representar apenas a parte visível do problema.

O “Copy Fail” sobreviveu por quase uma década dentro de um código-fonte aberto amplamente revisado e, em seguida, foi detectado em cerca de uma hora por um scanner assistido por IA, a partir de um único comando do operador. O Linux é a parte da pilha que é verificada porque pode ser verificada – abertamente, por qualquer pessoa. A área muito maior de firmware proprietário, kernels de fornecedores, protocolos legados e microcódigo de chips tem historicamente dependido da suposição de que código oculto significava bugs ocultos. Como argumenta Igor Seletskiy em “Open Source is the Tip of the Iceberg”(O código aberto é a ponta do iceberg), essa suposição está agora chegando ao fim. O “Copy Fail” é um dos primeiros indícios; não será um dos últimos.