CVE-2026-31431: perché Linux Copy Fail preoccupa

Una vulnerabilità nel kernel Linux, rimasta latente per quasi un decennio, è entrata improvvisamente nel radar operativo delle principali agenzie di sicurezza. CISA (Cybersecurity and Infrastructure Security Agency) ha inserito il bug Copy Fail – questo il nome della grave lacuna di sicurezza – nel suo catalogo KEV (Known Exploited Vulnerabilities, vulnerabilità conosciute e già usate dai criminali informatici), segnalando attività di sfruttamento reale.

Origine e natura tecnica della vulnerabilità Linux Copy Fail

La falla, identificata come CVE-2026-31431, rientra nella categoria delle local privilege escalation: come abbiamo spiegato nell’articolo di alcuni giorni fa, citato in apertura, Copy Fail nasce da un errore logico nel template crittografico di autenticazione del kernel.

Il problema scaturisce da una modifica introdotta nel 2017 nel modulo algif_aead, che gestisce alcune operazioni crittografiche. Con quel cambiamento è stato aggiunto il supporto alle operazioni in-place, cioè la possibilità di cifrare dati direttamente nella stessa area di memoria in cui si trovano, senza copiarli altrove.

Durante tali operazioni, il kernel usa una piccola area di memoria temporanea: a causa di un controllo mancante, il codice finisce per scrivere alcuni byte in una zona sbagliata, cioè nella page cache, la memoria che contiene le copie dei file utilizzati dal sistema.

Un attaccante può sfruttare questo comportamento per modificare il contenuto in memoria di un file eseguibile, per esempio un binario con privilegi elevati. Il file su disco resta identico, quindi i controlli di integrità non segnalano nulla, ma quando il sistema lo esegue, usa la versione alterata presente in RAM. Il programma modificato in memoria può così concedere accesso root all’attaccante sul sistema Linux.

Possibile schema di attacco con Copy Fail su Linux (fonte: Microsoft)

Ambienti cloud e container: il vero punto critico

Perché CISA ha immediatamente elevato il livello d’allerta? Perché un processo compromesso all’interno di un container può sfruttare Copy Fail per uscire dall’isolamento.

Non servono tecniche avanzate come race condition o brute force su indirizzi di memoria: il livello di complessità è basso e un aggressore può così arrivare a eseguire codice fuori dai confini di un ambiente protetto. Si pensi alle configurazioni basate su Docker, LXC e Kubernetes: se il modulo algif_aead è attivo sul kernel host può verificarsi l’esecuzione di codice arbitrario al di fuori del container.

Oltretutto, come abbiamo visto nell’articolo citato nell’introduzione, bastano poche righe di Python, circa 732 byte, per ottenere un’escalation a root. Versioni alternative in Go e Rust mostrano già variazioni nella sequenza di chiamate di sistema, rendendo più complessa la difesa basata su pattern statici.

Come verificare se un sistema è vulnerabile

La verifica non richiede strumenti complessi, ma va fatta con attenzione. Prima cosa: controllare la versione del kernel: le release antecedenti a 6.18.22, 6.19.12 e 7.0 risultano vulnerabili. Un comando semplice:

uname -r

Se il kernel rientra nel range 2017-2026 senza patch correttive, il rischio è concreto.

Il secondo controllo consiste nel verificare la presenza del modulo algif_aead. Basta eseguire quanto segue:

lsmod | grep algif_aead

Se il modulo è caricato, il sistema espone la superficie d’attacco. Nei sistemi in cui la funzionalità è compilata direttamente nel kernel (CONFIG_CRYPTO_USER_API_AEAD=y), la verifica richiede l’analisi della configurazione:

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Infine, gli ambienti containerizzati meritano un controllo aggiuntivo: è bene verificare se i container possono accedere ad AF_ALG. In molti casi è possibile di default, quindi il rischio si propaga automaticamente.

Mitigazioni tecniche e workaround

L’aggiornamento del kernel resta la soluzione definitiva. Il fix corregge la validazione dei buffer nelle operazioni crittografiche in-place. Se l’update non è immediatamente possibile, si può intervenire sul modulo vulnerabile. Disabilitare algif_aead riduce drasticamente il rischio:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

rmmod algif_aead

Nei sistemi con supporto integrato nel kernel, si può usare il parametro di boot initcall_blacklist per bloccarne l’inizializzazione.

Va detto però che queste misure possono avere impatti su applicazioni che usano AF_ALG per operazioni crittografiche: serve quindi effettuare una valutazione tecnica prima di intervenire.

Considerazioni finali

Il fatto che un’agenzia federale come CISA abbia annoverato Copy Fail tra le vulnerabilità più pericolose, conferma che ci si trova dinanzi a un difetto sfruttabile su Linux con estrema semplicità.

Se da un lato è vero che di per sé non può essere utilizzato per sferrare attacchi da remoto, Copy Fail è comunque molto pericolosa perché può diventare parte integrante di una catena di attacchi più elaborata o essere utilizzata, in maniera piuttosto banale, per sfuggire all’ambiente isolato che caratterizza i container, con configurazioni basate su Docker, LXC e Kubernetes.

Per chi gestisce sistemi Linux, la priorità è aggiornare rapidamente, limitare gli accessi locali e monitorare i comportamenti anomali.