"Copy Fail": nuova vulnerabilità in Linux permette di divenire root senza permesso (aggiornato: 1 maggio 2026, ore 12:34)

Uno script Python di 732 byte è tutto ciò che serve a un utente locale con privilegi limitati per ottenere una shell di root su qualsiasi sistema Linux con un kernel compilato dal 2017 in poi. Nessuna race condition da vincere, nessun offset del kernel da indovinare, nessuna dipendenza esterna da installare. La vulnerabilità si chiama Copy Fail, è classificata come CVE-2026-31431 con un punteggio CVSS di 7.8, ed è stata resa pubblica il 29 aprile 2026. Un exploit funzionante è già disponibile. Se amministrate macchine Linux - specialmente nodi Kubernetes, runner CI/CD o ambienti multi-tenant - il momento di agire è adesso.

Otto anni nel kernel, nascosti in bella vista

La storia di Copy Fail inizia nel 2011, con l'aggiunta di authencesn, un wrapper crittografico AEAD utilizzato da IPsec. Nel 2015 arriva il supporto ai socket AEAD nell'interfaccia AF_ALG, la API crittografica esposta allo spazio utente. Nel 2017, il commit 72548b093ee3 introduce un'ottimizzazione in-place nel modulo algif_aead (algif_aead.c). Tre modifiche, sei anni, tre sviluppatori diversi con obiettivi del tutto ragionevoli - e l'interazione tra queste produce il difetto logico che oggi conosciamo come Copy Fail.

Il problema è concettualmente semplice: l'ottimizzazione del 2017 consente che pagine della page cache - la copia in memoria dei file su disco - finiscano nella scatterlist di destinazione scrivibile di un'operazione AEAD. Un processo senza privilegi può concatenare un socket AF_ALG con la chiamata di sistema splice() e ottenere una scrittura controllata di 4 byte su qualsiasi pagina della page cache appartenente a un file leggibile. Nessuna corsa critica da vincere, nessun allineamento temporale da azzeccare: è un difetto logico deterministico.

Quel che rende tutto particolarmente insidioso è ciò che succede dopo la scrittura. Il kernel non segna la pagina corrotta come "dirty" per la riscrittura su disco. Il file originale rimane intatto sul supporto fisico, ma la versione corrotta in memoria è immediatamente visibile a tutti i processi del sistema. Gli strumenti di verifica dell'integrità che confrontano checksum su disco non rilevano nulla. L'attacco non lascia tracce forensi persistenti.

Quattro passi verso root

L'exploit pubblicato dai ricercatori di Xint.io e Theori - scoperto con l'ausilio dello strumento di analisi AI Xint Code, partendo dall'intuizione del ricercatore Taeyang Lee - si articola in quattro fasi lineari:

1. Apertura di un socket AF_ALG e binding all'algoritmo authencesn(hmac(sha256),cbc(aes)).
2. Costruzione del payload shellcode.
3. Scrittura nella page cache della copia in memoria di un binario setuid, tipicamente /usr/bin/su.
4. Chiamata a execve("/usr/bin/su") per caricare lo shellcode iniettato ed eseguirlo con privilegi di root.

Lo script richiede Python 3.10 o superiore (per il supporto a os.splice) e utilizza esclusivamente moduli della libreria standard: os, socket, zlib. Niente compilazione, niente pacchetti aggiuntivi, niente adattamento per versione del kernel. 732 byte di codice che funzionano in modo affidabile a ogni esecuzione su un sistema vulnerabile.

Come hanno sintetizzato i ricercatori di Xint.io: «Un utente locale non privilegiato può scrivere quattro byte controllati nella page cache di qualsiasi file leggibile su un sistema Linux, e usare questo per ottenere i privilegi di root».

Peggio di Dirty Cow, peggio di Dirty Pipe

Il confronto con i predecessori illustri è inevitabile - e non è favorevole a nessuno dei due.

Dirty Cow (CVE-2016-5195, 2016) sfruttava una race condition nel sottosistema di memoria virtuale, richiedeva tentativi multipli e talvolta faceva crashare il sistema. Dirty Pipe (CVE-2022-0847, 2022) era specifico per determinate versioni del kernel e richiedeva una manipolazione precisa dei buffer delle pipe. Copy Fail non ha nessuno di questi limiti: deterministico, portabile su tutte le versioni del kernel dal 2017, senza adattamenti.

David Brumley di Bugcrowd ha inquadrato bene la questione: «Copy Fail è la stessa classe di primitiva, in un sottosistema diverso». Stessa categoria di attacco - corruzione mirata della page cache - ma in un sottosistema diverso e con proprietà operative molto più favorevoli all'attaccante.

Portabile, compatto, furtivo e capace di attraversare i confini dei container: queste quattro caratteristiche raramente si trovano insieme nella stessa vulnerabilità. La page cache è condivisa tra tutti i processi di un sistema, inclusi quelli in esecuzione in container separati. Copy Fail funziona quindi anche come primitiva di escape da container e come vettore di compromissione di nodi Kubernetes.

Chi è vulnerabile

In termini pratici: ogni distribuzione Linux che utilizza un kernel compilato tra il 2017 e la disponibilità della patch. I ricercatori hanno verificato direttamente l'exploit su Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 e SUSE 16. Alexander Peslyak (noto come Solar Designer), fondatore dell'Openwall Project, ha confermato la vulnerabilità anche su Rocky Linux 9.7.

L'elenco delle distribuzioni implicitamente interessate comprende Debian, Arch Linux, Fedora, AlmaLinux, Oracle Linux e le distribuzioni Linux embedded. Ubuntu 26.04 (Resolute) e i kernel successivi non sono affetti.

Va precisato un aspetto cruciale: Copy Fail richiede esecuzione locale di codice. Non è sfruttabile da remoto in modo diretto. Ma come hanno sottolineato i ricercatori di Theori: «Concatenalo con qualsiasi cosa ti permetta di ottenerlo - una RCE web che atterra in un account di servizio non privilegiato, un punto d'appoggio SSH, una PR malevola su un runner CI - e sei root». Qualsiasi punto d'appoggio locale, per quanto limitato, diventa la chiave d'accesso al pieno controllo del sistema.

Lo stato delle patch

La correzione nel ramo principale del kernel è il commit a664bf3d603d, che annulla l'ottimizzazione del 2017. È stato inserito il 1° aprile 2026. Le distribuzioni sono state notificate prima della divulgazione pubblica. L'avviso di CERT-EU del 29 aprile indicava che nessuna distribuzione aveva ancora rilasciato un pacchetto kernel corretto; le fonti del 30 aprile suggeriscono che alcune avessero già avviato il rilascio. La situazione è in evoluzione rapida.

La lista delle priorità di intervento stilata da CERT-EU e dai ricercatori:

• Massima priorità: nodi Kubernetes, runner CI/CD esposti a carichi di lavoro non fidati, piattaforme SaaS cloud che eseguono codice utente, cluster di container, sistemi Linux multi-tenant.
• Priorità successiva: server Linux standard, workstation a utente singolo.

Mitigazione immediata

Se la patch non è ancora disponibile per la vostra distribuzione, la contromisura più diretta è disabilitare il modulo kernel algif_aead in modo persistente:

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

Questa operazione non compromette il funzionamento di dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS e SSH. Potrebbe però impattare applicazioni configurate esplicitamente per utilizzare il motore afalg o che creano direttamente socket aead, skcipher o hash. Per verificare l'esposizione, il punto di partenza è lsof | grep AF_ALG.

Un'alternativa è bloccare la creazione di socket AF_ALG tramite seccomp. CERT-EU raccomanda specificamente di applicare questo blocco negli ambienti containerizzati e nelle pipeline di integrazione continua.

Un bug di interazione, e la domanda scomoda

Copy Fail mette a nudo la fragilità intrinseca dei sistemi complessi: tre modifiche al kernel introdotte nell'arco di sei anni da sviluppatori diversi, ognuna sensata presa singolarmente, che insieme dormivano indisturbate da circa otto anni. La scoperta assistita dall'intelligenza artificiale aggiunge una domanda scomoda: se uno strumento AI ha contribuito a trovare questo bug, quanti altri difetti di interazione simile restano sepolti nella base di codice del kernel?

Per gli amministratori di sistema il messaggio è senza sfumature. Un exploit pubblico, deterministico, che non richiede adattamento e che attraversa i confini dei container è già nelle mani di chiunque lo voglia usare. Ogni ora di ritardo nell'applicare la patch - o almeno la mitigazione - è un'ora in cui qualsiasi utente locale, qualsiasi servizio compromesso, qualsiasi runner CI con accesso non fidato può diventare root.

Fonti: xint.io, cert.europa.eu, helpnetsecurity.com