Em 29 de abril de 2026, a empresa de pesquisa de segurança Xint.io, em colaboração com a Theori, divulgou publicamente uma das vulnerabilidades mais impactantes já descobertas no kernel Linux. Batizada de “Copy Fail” e catalogada como CVE-2026-31431 com pontuação CVSS 7.8 (Alta), trata-se de uma falha lógica no subsistema criptográfico do kernel que permite a qualquer utilizador local sem privilégios obter acesso root completo em praticamente todas as distribuições Linux lançadas desde 2017.
O que torna esta vulnerabilidade excepcionalmente perigosa é a combinação de quatro características que raramente aparecem juntas: é portável (o mesmo script funciona em todas as distribuições testadas sem qualquer modificação), é minúscula (o exploit inteiro cabe em 732 bytes de Python), é furtiva (a corrupção ocorre apenas na cache de páginas em memória, sem alterar o ficheiro em disco, escapando a ferramentas de verificação de integridade tradicionais), e é cross-container (a cache de páginas é partilhada entre o host e todos os containers, tornando-a um vetor de escape de containers e comprometimento de nós Kubernetes).
A falha foi introduzida num commit de agosto de 2017 (72548b093ee3) e permaneceu silenciosamente explorável durante quase uma década. O patch no kernel mainline (a664bf3d603d) foi commitado em 1 de abril de 2026, e a divulgação coordenada ocorreu em 29 de abril de 2026.
Este artigo apresenta uma análise técnica completa do mecanismo de exploração, o código PoC (Proof of Concept), instruções detalhadas de mitigação manual (incluindo como verificar se a desabilitação do módulo afetará os serviços do servidor), e as lições que administradores de sistemas devem absorver deste incidente.
O Que é o AF_ALG e o Módulo algif_aead
Para compreender esta vulnerabilidade, é necessário entender dois componentes do kernel Linux que a maioria dos administradores nunca interagiu diretamente.
O AF_ALG é uma família de sockets que expõe o subsistema criptográfico do kernel ao espaço de utilizador (userspace). Qualquer utilizador sem privilégios pode abrir um socket AF_ALG, associá-lo a um algoritmo criptográfico e executar operações de encriptação ou desencriptação sobre dados arbitrários. Não são necessários privilégios de root. Esta interface foi concebida para que aplicações pudessem delegar operações criptográficas ao kernel sem necessidade de bibliotecas de espaço de utilizador.
O algif_aead é o módulo específico do kernel que implementa a interface AF_ALG para algoritmos do tipo AEAD (Authenticated Encryption with Associated Data). O AEAD é um padrão criptográfico que garante simultaneamente confidencialidade e integridade dos dados. O módulo algif_aead é carregado automaticamente pelo kernel quando uma aplicação cria um socket AF_ALG e solicita um algoritmo AEAD.
O ponto crucial é que a esmagadora maioria dos serviços e aplicações em servidores Linux não utiliza sockets AF_ALG. As operações criptográficas padrão como dm-crypt (encriptação de disco), LUKS, IPsec (no espaço de kernel, via xfrm), TLS/SSL (via OpenSSL ou GnuTLS), SSH e ligações HTTPS são todas realizadas internamente pelo kernel ou por bibliotecas de espaço de utilizador, sem passar pela interface AF_ALG. Esta informação é fundamental para a estratégia de mitigação que detalharemos mais adiante.
Visão Geral da Vulnerabilidade
A CVE-2026-31431 é uma falha lógica na interação entre três componentes do kernel: o template criptográfico authencesn (usado pelo IPsec para Extended Sequence Numbers), o mecanismo de operação in-place do módulo algif_aead (introduzido em 2017), e o sistema de splice() que permite transferir páginas da cache de páginas (page cache) diretamente para sockets sem cópia.
A falha permite que um utilizador local sem privilégios escreva 4 bytes controlados em qualquer posição da cache de páginas de qualquer ficheiro legível no sistema. Repetindo esta operação para cada bloco de 4 bytes de um shellcode, o atacante pode corromper a cópia em memória de um binário setuid (como /usr/bin/su) e, ao executá-lo, obter root.
A vulnerabilidade foi reportada à equipa de segurança do kernel Linux em 23 de março de 2026, o patch foi commitado em 1 de abril de 2026, o CVE foi atribuído em 22 de abril de 2026, e a divulgação pública ocorreu em 29 de abril de 2026.
Análise Técnica Detalhada
A análise técnica a seguir é baseada na pesquisa publicada pela Xint.io e pela Theori, com contribuição do investigador Taeyang Lee, que identificou a superfície de ataque durante trabalho prévio no kernelCTF.
A Causa Raiz: Páginas da Cache no Scatterlist Gravável
Quando um utilizador usa splice() para transferir dados de um ficheiro para um pipe e desse pipe para um socket AF_ALG, as páginas da cache de páginas (page cache pages) do ficheiro são passadas por referência ao socket, sem cópia. O scatterlist de entrada do socket passa a conter referências diretas às mesmas páginas físicas de memória que o kernel usa quando qualquer processo lê, mapeia (mmap) ou executa (execve) aquele ficheiro.
Para operações de desencriptação AEAD, o módulo algif_aead (desde a optimização de 2017) realiza a operação in-place: o mesmo scatterlist serve simultaneamente como entrada e saída para o algoritmo criptográfico. O código configura req->src = req->dst, ambos apontando para a mesma cadeia de scatterlist.
O scatterlist combinado tem duas regiões: o buffer de recepção do utilizador (que contém cópias dos dados AAD e ciphertext) e as páginas da tag de autenticação, que continuam a referenciar as páginas originais da cache do ficheiro alvo. Essas páginas da cache estão agora numa posição gravável do scatterlist de destino.
O Gatilho: A Escrita Scratch do authencesn
O template authencesn é um wrapper AEAD usado pelo IPsec para suporte a Extended Sequence Numbers (ESN, RFC 4303). O IPsec usa números de sequência de 64 bits divididos em duas metades: seqno_hi (bytes 0 a 3 do AAD) e seqno_lo (bytes 4 a 7). Para calcular o HMAC, o authencesn precisa rearranjar estes bytes. Ele faz isso usando o buffer de destino do chamador como espaço temporário (scratch space).
A operação crítica está na função crypto_authenc_esn_decrypt(), que executa uma escrita de 4 bytes na posição dst[assoclen + cryptlen], ou seja, além do limite do buffer legítimo de saída. O algoritmo trata essa posição como memória descartável, sem nunca restaurar os bytes originais.
Nenhum outro algoritmo AEAD standard do kernel faz isto. GCM, CCM e o authenc regular confinam todas as suas escritas à área legítima de saída. Apenas o authencesn escreve além do limite.
No caminho in-place do AF_ALG, esta escrita cruza do buffer de saída do utilizador para as páginas da cache de páginas do ficheiro alvo que foram encadeadas no scatterlist. A função scatterwalk_map_and_copy percorre o scatterlist, mapeia a página da cache via kmap_local_page, e escreve os 4 bytes de seqno_lo diretamente na cópia em memória do ficheiro.
O atacante controla três elementos: qual ficheiro (qualquer ficheiro legível pelo utilizador corrente), qual posição (determinada pela escolha do offset do splice, comprimento do splice e valor do assoclen) e qual valor (os 4 bytes vêm dos bytes 4 a 7 do AAD, construídos pelo atacante no sendmsg()).
Como Isto Aconteceu: Cronologia da Falha
Em 2011, o authencesn foi adicionado ao kernel para suportar ESN do IPsec. Desde o início, usava o buffer de destino como espaço temporário. Isto era inofensivo na época porque o único chamador era o subsistema xfrm interno do kernel.
Em 2015, o AF_ALG ganhou suporte AEAD (algif_aead.c), com um caminho splice() que podia entregar páginas da cache de páginas ao scatterlist criptográfico. No mesmo ano, o authencesn foi convertido para a nova interface AEAD. Mas neste ponto o AF_ALG usava operação out-of-place: req->src e req->dst eram scatterlists separados. As páginas da cache estavam em src (somente leitura) e a escrita scratch ia para dst (buffer do utilizador). Ainda não explorável.
Em agosto de 2017, uma optimização foi adicionada ao algif_aead.c (commit 72548b093ee3) para realizar operações AEAD in-place. O código copiava os dados AAD e ciphertext do scatterlist TX para o buffer RX, mas encadeava as páginas da tag por referência usando sg_chain(). Depois definia req->src = req->dst. As páginas da cache de páginas passaram a estar no scatterlist de destino gravável. A escrita scratch do authencesn na posição dst[assoclen + cryptlen] passou a atingir essas páginas encadeadas da cache.
Ninguém relacionou a optimização de 2017 com as escritas scratch do authencesn nem com o uso de páginas da cache via splice. Cada alteração era razoável isoladamente. A vulnerabilidade existe na interseção das três, e permaneceu silenciosamente explorável durante quase uma década.
O Exploit: PoC de 732 Bytes
O exploit foi publicado pela Theori no repositório GitHub https://github.com/theori-io/copy-fail-CVE-2026-31431 e está também disponível em https://copy.fail/exp. É um script Python de aproximadamente 10 linhas (732 bytes) que utiliza apenas módulos da biblioteca standard: os, socket e zlib. Requer Python 3.10 ou superior devido ao uso de os.splice.
O fluxo do exploit segue quatro passos:
Passo 1: Configuração do socket. O script abre um socket AF_ALG (família 38, tipo SOCK_SEQPACKET) e associa-o ao algoritmo authencesn(hmac(sha256),cbc(aes)). Define uma chave e aceita um socket de pedido. Nenhum privilégio é necessário.
Passo 2: Construção da escrita. Para cada bloco de 4 bytes do shellcode a injetar, o script constrói um par sendmsg() + splice(). O sendmsg fornece o AAD onde os bytes 4 a 7 carregam os 4 bytes a escrever (seqno_lo). O splice fornece as páginas da cache do ficheiro alvo (/usr/bin/su) como ciphertext e tag. Os parâmetros AEAD (assoclen, offset do splice, comprimento do splice) são calculados para que dst[assoclen + cryptlen] caia exatamente no offset desejado dentro da secção .text do binário /usr/bin/su.
Passo 3: Disparo da escrita. O recv() dispara a operação de desencriptação. Dentro do authencesn, o kernel lê os bytes ESN do AAD e escreve seqno_lo na posição dst[assoclen + cryptlen]. O scatterwalk cruza do buffer de saída para a página encadeada da cache. Quatro bytes são escritos na cópia em memória do /usr/bin/su. O HMAC é calculado e falha (o ciphertext é fabricado). O recvmsg retorna um erro. Mas a página da cache já está corrompida.
Passo 4: Execução. Após todos os blocos serem escritos, o script chama execve("/usr/bin/su"). O kernel carrega o binário a partir da cache de páginas. A versão em cache contém o shellcode injetado. Como su é setuid-root, o shellcode executa com UID 0. Root obtido.
O pseudocódigo simplificado do exploit é:
a = socket.socket(38, 5, 0) # AF_ALG, SOCK_SEQPACKET
a.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))
# ... set key, accept request socket u ...
u.sendmsg([b"A"*4 + payload_chunk], [cmsg_headers], MSG_MORE)
os.splice(target_fd, pipe_wr, offset)
os.splice(pipe_rd, alg_fd, offset)
u.recv(...) # dispara decrypt -> escrita na page cache
# Repetir para cada bloco de 4 bytes
os.execve("/usr/bin/su", ...) # rootA Xint.io confirmou a execução bem-sucedida do mesmo script, sem qualquer modificação, nas seguintes combinações de distribuição e kernel: Ubuntu 24.04 LTS (kernel 6.17.0-1007-aws), Amazon Linux 2023 (kernel 6.18.8-9.213.amzn2023), RHEL 10.1 (kernel 6.12.0-124.45.1.el10_1) e SUSE 16 (kernel 6.12.0-160000.9-default).
Comparação com Dirty Cow e Dirty Pipe
A Copy Fail pertence à mesma família de vulnerabilidades de escalação de privilégios via manipulação da cache de páginas, mas apresenta diferenças significativas em relação aos seus predecessores.
O Dirty Cow (CVE-2016-5195) exigia vencer uma condição de corrida (race condition) no subsistema de Copy-on-Write da VM. Necessitava de múltiplas tentativas e por vezes crashava o sistema.
O Dirty Pipe (CVE-2022-0847) era específico a determinadas versões do kernel e requeria manipulação precisa de buffers de pipe.
O Copy Fail é uma falha lógica em linha reta (straight-line). Dispara sem condições de corrida, sem retentativas e sem janelas de timing propensas a crash. É portável entre distribuições e arquitecturas, funciona com o mesmo script em todo o lado, e a escrita na cache de páginas não é marcada como “dirty” pelo kernel, escapando a verificações de integridade baseadas em checksums do disco.
Impacto em Containers e Kubernetes
A cache de páginas do Linux é partilhada entre todos os processos do sistema, incluindo processos dentro de containers. Isto significa que a Copy Fail não é apenas uma escalação de privilégios local: é um primitivo de escape de containers. Um processo sem privilégios dentro de um container pode corromper a cache de páginas de um binário setuid no host e obter root no nó.
A Xint.io anunciou uma segunda parte da pesquisa focada especificamente em escape de containers e comprometimento de nós Kubernetes, intitulada “From Pod to Host”. Testes realizados por investigadores independentes confirmaram que o perfil seccomp RuntimeDefault do Kubernetes (tanto no Talos/containerd como no EKS/containerd) não bloqueia sockets AF_ALG. É necessário um perfil seccomp personalizado que negue explicitamente a criação de sockets da família AF_ALG para mitigar o risco em ambientes containerizados.
Distribuições Afetadas e Status dos Patches
A vulnerabilidade afeta todos os kernels Linux compilados entre agosto de 2017 (commit 72548b093ee3) e a aplicação do patch (commit a664bf3d603d). Isto abrange essencialmente todas as distribuições Linux mainstream em uso.
O patch mainline foi commitado em 1 de abril de 2026, e as principais distribuições começaram a disponibilizar kernels corrigidos nos seus repositórios. O estado dos patches por distribuição é: Ubuntu emitiu advisories e patches (https://ubuntu.com/security/CVE-2026-31431), Debian publicou o tracker (https://security-tracker.debian.org/tracker/CVE-2026-31431), SUSE disponibilizou patches (https://www.suse.com/security/cve/CVE-2026-31431.html), Amazon Linux emitiu advisory (https://explore.alas.aws.amazon.com/CVE-2026-31431.html), e Red Hat, que inicialmente considerou adiar a correção, alterou a sua posição e anunciou patches iminentes (https://access.redhat.com/security/cve/cve-2026-31431).
Mitigação Manual Imediata (Antes do Patch do Kernel)
A atualização do kernel é a correção definitiva. No entanto, para servidores onde o reboot ou a atualização do kernel não podem ser realizados imediatamente, existe uma mitigação manual eficaz: desabilitar o módulo algif_aead.
Passo 1: Verificar se o Módulo Está Carregado
Antes de qualquer ação, verifique o estado atual do módulo:
lsmod | grep algif_aeadSe este comando não retornar nenhuma saída, o módulo não está carregado neste momento. No entanto, ele pode ser carregado automaticamente pelo kernel quando uma aplicação solicita um socket AF_ALG AEAD. Por isso, é necessário não apenas descarregá-lo (se estiver carregado) mas também impedir que seja carregado no futuro.
Passo 2: Verificar se Algum Serviço Utiliza AF_ALG
Esta é a verificação fundamental para garantir que a mitigação não prejudicará nenhum serviço do servidor:
# Verificar se existem sockets AF_ALG ativos
ss -xa | grep AF_ALG
# Verificar se algum processo tem ficheiros AF_ALG abertos
lsof 2>/dev/null | grep AF_ALG
# Verificar se alguma aplicação está a usar o módulo
lsmod | grep -E "algif_aead|algif_hash|algif_skcipher" | awk '{print $3}'Se todos estes comandos retornarem vazio, nenhum serviço no servidor está a utilizar sockets AF_ALG. Esta é a situação normal na vasta maioria dos servidores.
Para contexto sobre o que não é afetado pela desabilitação do módulo algif_aead:
O dm-crypt/LUKS (encriptação de disco) utiliza a API criptográfica do kernel internamente, mas não através de sockets AF_ALG. Não é afetado.
O IPsec (VPNs via strongSwan, Libreswan, etc.) utiliza o subsistema xfrm do kernel diretamente. Não passa por AF_ALG. Não é afetado.
O TLS/SSL (OpenSSL, GnuTLS, servidores web HTTPS) opera inteiramente em espaço de utilizador ou via kTLS. Não é afetado.
O SSH utiliza bibliotecas criptográficas de espaço de utilizador. Não é afetado.
O Docker/Podman/Kubernetes não utiliza AF_ALG para operações de containers. Não é afetado.
As bases de dados (MySQL, PostgreSQL, MongoDB) utilizam bibliotecas criptográficas de espaço de utilizador. Não são afetadas.
Os servidores web (Apache, Nginx) e serviços de e-mail não utilizam AF_ALG. Não são afetados.
Em resumo, a interface AF_ALG é utilizada por um número extremamente reduzido de aplicações especializadas. A esmagadora maioria dos servidores de produção não tem qualquer dependência deste módulo.
Passo 3: Desabilitar o Módulo
Execute os seguintes comandos como root:
# Criar regra para impedir o carregamento futuro do módulo
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
# Descarregar o módulo se estiver carregado
rmmod algif_aead 2>/dev/null || trueO ficheiro criado em /etc/modprobe.d/ persiste entre reboots. Quando o kernel tenta carregar o módulo algif_aead (seja automaticamente ou por pedido), o modprobe executa /bin/false em vez de carregar o módulo, impedindo efetivamente o seu carregamento.
Passo 4: Verificar a Mitigação
# Confirmar que o módulo não está carregado
lsmod | grep algif_aead
# Deve retornar vazio
# Confirmar que o ficheiro de configuração existe
cat /etc/modprobe.d/disable-algif-aead.conf
# Deve mostrar: install algif_aead /bin/false
# Confirmar que sockets AF_ALG AEAD não podem ser criados
python3 -c "
import socket
try:
s = socket.socket(38, 5, 0)
s.bind(('aead', 'authencesn(hmac(sha256),cbc(aes))'))
print('[!] ALERTA: Sistema permite criação de socket AF_ALG. Provavelmente vulnerável.')
except Exception as e:
print(f'[+] SEGURO: Não é possível criar o socket. ({e})')
"Se o teste Python retornar [+] SEGURO, a mitigação está ativa e o servidor está protegido contra esta vulnerabilidade.
Caso Especial: Módulo Compilado Diretamente no Kernel (Builtin)
Em algumas distribuições, nomeadamente RHEL 9.x e certas versões do CentOS, o módulo algif_aead pode estar compilado diretamente no kernel (builtin) em vez de ser um módulo carregável. Neste caso, os comandos rmmod e modprobe -r falharão com o erro Module algif_aead is builtin.
Se isto acontecer no seu servidor:
# Verificar se o módulo é builtin
modprobe -r algif_aead 2>&1 | grep -i builtinSe obtiver a mensagem Module algif_aead is builtin, o ficheiro em /etc/modprobe.d/ não terá efeito. Neste caso, as alternativas são:
Opção A: Bloquear via seccomp. Se o servidor corre workloads containerizadas, aplique um perfil seccomp que negue a criação de sockets da família AF_ALG (família 38).
Opção B: Recompilar o kernel com CONFIG_CRYPTO_USER_API_AEAD=n ou CONFIG_CRYPTO_USER_API_AEAD=m (para torná-lo módulo descarregável).
Opção C: Priorizar a atualização do kernel. Se o módulo é builtin, a única correção fiável sem recompilação é atualizar para um kernel que contenha o patch a664bf3d603d.
Mitigação via Ansible para Múltiplos Servidores
Para administradores que gerem frotas de servidores, o seguinte playbook Ansible aplica a mitigação em todos os hosts:
- hosts: all_servers
become: true
tasks:
- name: Criar regra para desabilitar algif_aead
copy:
dest: /etc/modprobe.d/disable-algif-aead.conf
content: |
install algif_aead /bin/false
owner: root
group: root
mode: '0644'
- name: Verificar se algif_aead está carregado
shell: lsmod | grep -w algif_aead
register: algif_loaded
failed_when: false
changed_when: false
- name: Descarregar módulo algif_aead
command: rmmod algif_aead
when: algif_loaded.rc == 0Executar com:
ansible-playbook disable-algif-aead.yaml -i inventory.yamlAtualização Definitiva: Patch do Kernel
A mitigação manual é uma medida temporária. A solução definitiva é atualizar o kernel para uma versão que contenha o commit a664bf3d603d ou posterior.
Comandos de atualização por distribuição:
# Ubuntu / Debian
apt update && apt upgrade -y
# Verificar: uname -r (deve ser versão corrigida)
# RHEL / CentOS / AlmaLinux / Rocky Linux / Fedora
dnf update kernel -y
# ou: yum update kernel -y
# Amazon Linux 2 / Amazon Linux 2023
yum update kernel -y
# SUSE / openSUSE
zypper update kernel-default
# Arch Linux
pacman -SyuApós a atualização, é necessário reiniciar o servidor para que o novo kernel entre em vigor:
# Verificar versão do kernel após reboot
uname -rComo Reverter o PoC (Se Executou por Teste)
Se por algum motivo o PoC foi executado num servidor de teste e o binário /usr/bin/su ficou corrompido, a reversão é simples porque a corrupção existe apenas na cache de páginas em memória. O ficheiro em disco permanece inalterado. Existem duas formas de reverter:
# Opção 1: Reiniciar o servidor (a cache é limpa)
reboot
# Opção 2: Forçar o flush da cache de páginas (sem reboot)
sync && echo 3 > /proc/sys/vm/drop_cachesApós qualquer uma destas operações, o binário /usr/bin/su será recarregado a partir do disco (limpo) na próxima execução.
A Correção no Kernel
O patch (commit a664bf3d603d) reverte o módulo algif_aead.c para operação out-of-place, removendo inteiramente a optimização de 2017. A tag Fixes: no commit aponta para 72548b093ee3, o commit que introduziu o design in-place, confirmando que o encadeamento de páginas da cache no scatterlist de destino gravável é a causa raiz.
Antes do patch, req->src e req->dst apontavam para o mesmo scatterlist (operação in-place), onde páginas da cache de ficheiros via splice() estavam encadeadas na região gravável de destino. Após o patch, req->src aponta para o scatterlist TX (que pode conter páginas da cache) e req->dst aponta para o scatterlist RX (o buffer do utilizador). Apenas o AAD é copiado de src para dst. Todo o mecanismo sg_chain que ligava páginas da cache ao scatterlist gravável de destino foi removido.
Como afirmado no commit: “There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings.”
Cronologia da Divulgação Coordenada
A divulgação seguiu um processo responsável: em 23 de março de 2026 a vulnerabilidade foi reportada à equipa de segurança do kernel Linux, em 24 de março foi recebido o acknowledgment inicial, em 25 de março os patches foram propostos e revisados, em 1 de abril os patches foram commitados no kernel mainline, em 22 de abril o CVE-2026-31431 foi atribuído, e em 29 de abril de 2026 ocorreu a divulgação pública com a publicação da análise técnica e do PoC.
Contexto: Descoberta Assistida por IA
A vulnerabilidade foi identificada pelo investigador Taeyang Lee da Theori, cujo trabalho anterior no kernelCTF mapeou a superfície de ataque do AF_ALG. Lee usou o Xint Code, uma ferramenta de pesquisa de segurança baseada em IA da Xint.io, para escalar a análise a todo o subsistema criptográfico do kernel.
O “operator prompt” fornecido ao Xint Code foi relativamente simples: “This is the linux crypto/ subsystem. Please examine all codepaths reachable from userspace syscalls. Note one key observation: splice() can deliver page-cache references of read-only files (including setuid binaries) to crypto TX scatterlists.”
Após aproximadamente uma hora de análise, a ferramenta completou o scan, e a Copy Fail foi identificada como a descoberta de maior severidade no relatório. A Theori informou que o scan também identificou outras vulnerabilidades de alta severidade, incluindo outra escalação de privilégios, que permanecem no processo de divulgação responsável.
Este caso exemplifica uma tendência mais ampla na indústria: ferramentas de pesquisa de vulnerabilidades assistidas por IA estão a aumentar significativamente o volume de bugs reportados. A Microsoft reportou recentemente o segundo maior número de patches de sempre, atribuído em parte a equipas de segurança que usam IA para caçar bugs. O programa Internet Bug Bounty (IBB) suspendeu temporariamente a atribuição de prémios enquanto avalia como gerir o volume crescente de reports.
Recomendações Finais
Para administradores de servidores Linux, a ação imediata consiste em verificar se o módulo algif_aead está a ser usado por algum serviço (com os comandos ss -xa | grep AF_ALG e lsof | grep AF_ALG), desabilitá-lo imediatamente se não estiver em uso, e planear a atualização do kernel o mais brevemente possível.
Para equipas que gerem ambientes containerizados e Kubernetes, é necessário aplicar perfis seccomp personalizados que bloqueiem explicitamente sockets AF_ALG (família 38), pois o perfil RuntimeDefault não oferece proteção contra esta vulnerabilidade.
Para equipas de segurança, recomenda-se adicionar a CVE-2026-31431 ao pipeline de gestão de vulnerabilidades com prioridade alta, monitorizar tentativas de criação de sockets AF_ALG nos logs de auditoria (auditd), e considerar a implementação de políticas seccomp por defeito que restrinjam famílias de sockets não necessárias.
Referências
- Xint.io / Theori (Análise Técnica Original): https://xint.io/blog/copy-fail-linux-distributions
- Copy Fail (Site Oficial): https://copy.fail/
- Repositório GitHub com PoC e Discussões: https://github.com/theori-io/copy-fail-CVE-2026-31431
- The Hacker News: https://thehackernews.com/2026/04/new-linux-copy-fail-vulnerability.html
- The Register: https://www.theregister.com/2026/04/30/linux_cryptographic_code_flaw/
- NVD (CVE-2026-31431): https://nvd.nist.gov/vuln/detail/CVE-2026-31431
- Commit do Patch no Kernel Mainline: https://git.kernel.org/stable/c/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
- Commit Vulnerável Original (2017): https://github.com/torvalds/linux/commit/72548b093ee3
- Red Hat Advisory: https://access.redhat.com/security/cve/cve-2026-31431
- Ubuntu Advisory: https://ubuntu.com/security/CVE-2026-31431
- Debian Tracker: https://security-tracker.debian.org/tracker/CVE-2026-31431
- SUSE Advisory: https://www.suse.com/security/cve/CVE-2026-31431.html
- Amazon Linux Advisory: https://explore.alas.aws.amazon.com/CVE-2026-31431.html
- Guia de Mitigação Rápida (Sam James): https://www.samdjames.uk/docs/platforms/magento/security/copy-fail-cve-2026-31431/
- SentinelOne (Análise CVE): https://www.sentinelone.com/vulnerability-database/cve-2026-31431/
- Discussão sobre RHEL Builtin (GitHub Issue #30): https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/30
- Teste de Seccomp em Kubernetes (AF_ALG): https://juliet.sh/blog/we-tested-copy-fail-in-kubernetes-pss-restricted-runtime-default-af-alg
Amante por tecnologia Especialista em Cibersegurança e Big Data, Formado em Administração de Infraestrutura de Redes, Pós-Graduado em Ciências de Dados e Big Data Analytics e Machine Learning, Com MBA em Segurança da Informação, Escritor do livro ” Cibersegurança: Protegendo a sua Reputação Digital”.
