CVE-2026-31431 — Copy Fail

Escalatazione dei privilegi locale nel template crittografico authencesn del kernel Linux tramite AF_ALG + splice().
Divulgato il 29 aprile 2026 da Theori (Xint Code).

Panoramica

Riepilogo della vulnerabilità

Un difetto logico nel wrapper AEAD authencesn del kernel consente a un utente locale non privilegiato di eseguire una scrittura deterministica e controllata di 4 byte nella page cache di qualsiasi file leggibile sul sistema — inclusi i binari setuid come /usr/bin/su.

La causa principale è un'ottimizzazione del 2017 per l'elaborazione in-place che inseriva le pagine della page cache in uno scatterlist scrivibile. L'algoritmo authencesn scrive 4 byte di dati scratch al di fuori della regione di output prevista durante il riarrangiamento dell'Extended Sequence Number. A causa della struttura dello scatterlist introdotta dall'ottimizzazione, quei 4 byte finiscono nella page cache di un file fornito tramite splice() — bypassando completamente i permessi dei file.

Nessuna race condition. Nessun tentativo. Nessun rischio di crash. Deterministico su tutte le distribuzioni testate.

Confronto con lavori precedenti

Versioni interessate

Vulnerabili: kernel Linux 4.14 fino a 6.18.21 e 6.19.x prima di 6.19.12.

Tutte le principali distribuzioni che forniscono kernel in questo intervallo sono interessate, tra cui:

Non interessate: Ubuntu 26.04 (Resolute) e successive.

Mitigazione

Opzione 1 — Patch (consigliata)

Aggiornare a un kernel contenente il commit mainline a664bf3d603d, che ripristina l'ottimizzazione in-place del 2017.

# Ubuntu / Debian
sudo apt update && sudo apt upgrade -y && sudo reboot

# RHEL / AlmaLinux / Amazon Linux
sudo dnf clean metadata && sudo dnf upgrade && sudo reboot

# SUSE
sudo zypper refresh && sudo zypper update kernel-default && sudo reboot

Opzione 2 — Disabilitare algif_aead (temporaneo)

Se non è possibile applicare subito la patch, disabilitare il modulo vulnerabile per chiudere la superficie di attacco.

Nota per i sistemi RHEL-family: algif_aead è compilato nel kernel su RHEL/AlmaLinux/CentOS (CONFIG_CRYPTO_USER_API_AEAD=y). Il workaround modprobe.d non funziona su questi sistemi. Usare invece il metodo initcall_blacklist.

Debian/Ubuntu (modulo caricabile):

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead 2>/dev/null || true

RHEL-family (integrato nel kernel — richiede riavvio):

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

Verificare dopo il riavvio:

grep initcall_blacklist /proc/cmdline

Effetti di questo workaround

Opzione 3 — seccomp (difesa in profondità)

Per carichi di lavoro non fidati — container, runner CI, ambienti sandbox — bloccare la creazione di socket AF_ALG tramite policy seccomp indipendentemente dallo stato della patch. Questo limita la superficie di attacco anche su kernel vulnerabili.

Rilevamento

Verificare se algif_aead è attualmente caricato o in uso:

# Verificare se il modulo è caricato
lsmod | grep algif_aead

# Verificare se qualche processo ha un socket AF_ALG aperto
lsof | grep AF_ALG
ss -xa | grep alg

Le firme di rilevamento runtime sono disponibili in Sysdig Secure (regola: AF_ALG Page Cache Poisoning Leading to Privilege Escalation).

Riferimenti

Cronologia della divulgazione

Autore

xD The Watcher — Red Teamer, Ethical Hacker & AI Security Researcher
GitHub: @xd20111
Blog: yourhacker

Note

Questo repository documenta la vulnerabilità a scopo di ricerca e difesa. Per l'analisi tecnica autorevole e il PoC ufficiale, fare riferimento alla divulgazione di Theori collegata sopra.

Se il proprio modello di minaccia include multi-tenancy con kernel condiviso — container su host condiviso, runner CI, farm di build — il confine di isolamento è ora significativamente più debole fino alla patch. L'isolamento a livello hardware o VM è la risposta corretta, non i confini dei namespace.