Copy Fail técnico: AF_ALG, splice e page cache por trás da CVE-2026-31431

abril 29, 2026

Ilustração técnica de AF_ALG, splice e page cache no Copy Fail

Copy Fail, CVE-2026-31431, é uma vulnerabilidade de elevação local de privilégios no kernel Linux. A versão curta é que a combinação de AF_ALG, splice(), o template criptográfico authencesn e uma otimização in-place de algif_aead permite uma escrita controlada de 4 bytes no page cache. Para equipes de segurança, a explicação útil é operacional: houve uma falha de limite entre scatterlists que nunca deveriam compartilhar um destino gravável.

A peça sensível é AF_ALG, a interface de sockets que expõe primitivas criptográficas do kernel ao userspace. Com splice(), o userspace pode mover dados de um arquivo para um pipe sem copiar byte por byte. Nesse caminho, o kernel pode manter referências a páginas do page cache. Quando essas páginas acabam encadeadas em uma scatterlist tratada como destino pelo subsistema criptográfico, surge a condição perigosa.

Segundo a análise da Xint Code, authencesn usa parte do buffer de destino como espaço temporário para reorganizar bytes relacionados a ESN. Esse comportamento fazia sentido nas premissas originais, mas se tornou perigoso quando combinado ao caminho AF_ALG AEAD in-place introduzido anos antes. A escrita temporária ultrapassa a região legítima e alcança páginas que representam a cópia em memória de um arquivo legível.

Por que o page cache muda o impacto

O page cache não é uma cópia privada do processo atacante. Ele é a representação em memória que outros caminhos do sistema podem ler. Se essa cópia pertence a um binário setuid, uma mudança temporária em memória pode afetar a execução sem modificar o arquivo persistente em disco. Por isso, verificações baseadas apenas no arquivo físico não bastam para avaliar impacto.

A escrita reportada é pequena: 4 bytes por operação. Mas tamanho não define severidade sozinho. Uma primitiva pequena, confiável e repetível pode ser suficiente se o alvo for sensível. O valor técnico do Copy Fail está na combinação de controle, confiabilidade e portabilidade entre kernels e distribuições afetados, não no tamanho de um PoC.

Isso também explica o debate de severidade. A falha exige execução local e não fornece acesso remoto inicial. Isso leva vários fornecedores a classificá-la como média ou moderada. Ao mesmo tempo, em ambientes multi-tenant, CI, contêineres ou sandboxes, a fronteira entre “local” e “crítico” é fina: executar código local é exatamente o serviço oferecido.

A correção

A correção principal retorna algif_aead à operação out-of-place. Em vez de permitir que origem e destino compartilhem uma estrutura combinada com páginas do page cache encadeadas, o fix separa as scatterlists de entrada e saída. Isso remove a condição que permitia que a escrita temporária de authencesn alcançasse memória associada ao arquivo.

Para operadores, a mensagem prática é clara: atualizar o kernel da distribuição para uma versão que inclua o fix. Não é recomendável portar commits manualmente, salvo quando a equipe mantém seu próprio kernel e tem processo de validação. Em frotas comuns, a unidade de remediação é o pacote de kernel do fornecedor, a imagem base ou o kernel gerenciado do provedor cloud.

Como mitigação temporária, o site Copy Fail recomenda desabilitar algif_aead ou bloquear a criação de sockets AF_ALG com políticas como seccomp para workloads não confiáveis. É uma redução de superfície razoável, especialmente para runners e sandboxes, mas precisa ser testada. Alguns ambientes embarcados ou configurações explícitas de offload criptográfico podem depender de AF_ALG.

Checklist defensivo

Primeiro, faça inventário dos kernels reais, não apenas das distribuições. Versões de kernel, backports e builds cloud importam mais que nomes comerciais. Segundo, identifique hosts onde usuários, contêineres ou jobs de CI compartilham o kernel. Esses sistemas têm prioridade sobre servidores de usuário único.

Terceiro, revise se as políticas de sandbox bloqueiam famílias de sockets desnecessárias. Muitos workloads nunca precisam abrir AF_ALG; se seu modelo executa código de terceiros, bloquear superfícies não usadas reduz espaço de exploração além deste incidente. Quarto, separe runners para código externo e evite reutilizar hosts privilegiados em pipelines de baixa confiança.

Quinto, valide com advisories do fornecedor. A discussão pública contém detalhes úteis, mas também erros e divergências, incluindo a menção debatida a uma versão inexistente do RHEL na página pública. Para gestão de mudanças, use trackers oficiais e registre o estado por plataforma.

O que o patch não resolve

Corrigir Copy Fail não elimina o problema geral de executar código não confiável em kernels compartilhados. Também não substitui isolamento forte, controle de syscalls, separação de tenants ou rotação de imagens base. A lição técnica é mais ampla: otimizações in-place que misturam referências de origens diferentes precisam de auditoria cuidadosa quando há caminhos zero-copy a partir do userspace.

Equipes de plataforma devem revisar testes de regressão ao redor de splice(), page cache, APIs criptográficas expostas ao userspace e sandboxes que permitem syscalls pouco usadas. Copy Fail mostra como uma decisão localmente razoável pode se tornar perigosa quando outro subsistema muda o modelo de memória anos depois.

A conclusão não é pânico. É prioridade. Onde um possível atacante já pode executar código local, como CI, Linux multi-tenant, Kubernetes, desktops compartilhados ou hosts de desenvolvimento, uma elevação local confiável não é detalhe secundário. É uma falha no limite de confiança.