Una vulnerabilità nel kernel Linux è rimasta nascosta per quasi un decennio, esponendo una quantità enorme di sistemi a un’escalation di privilegi locale con un’affidabilità quasi totale. Il caso si chiama Copy Fail, è stato catalogato come CVE-2026-31431, e ha qualcosa di particolarmente inquietante: basta uno script Python da appena 732 byte per ottenere una shell root su distribuzioni diverse, senza nemmeno dover adattare il codice. Nessun ritocco, nessun aggiustamento. Funziona e basta. Il problema affonda le radici in alcune modifiche introdotte nel 2017, e riguarda componenti presenti nelle configurazioni standard di praticamente tutte le distribuzioni più diffuse.
Il cuore della faccenda sta nel modulo authencesn, parte dell’implementazione della crittografia AEAD (Authenticated Encryption with Associated Data, una tecnica che unisce cifratura e verifica dell’integrità dei dati) all’interno del kernel. In condizioni normali, le operazioni crittografiche lavorano su strutture chiamate scatterlist, che descrivono buffer di memoria sorgente e destinazione. Nel 2017, però, è stata introdotta un’ottimizzazione in place pensata per ridurre copie di dati superflue. Peccato che questa modifica abbia eliminato una separazione fondamentale tra buffer di input e output.
Quello che succede, nella pratica, è che durante l’elaborazione di dati autenticati una scrittura di 4 byte va oltre il limite previsto, finendo in un’area di memoria che non dovrebbe essere toccata. Il passaggio critico avviene quando si combinano tre elementi: il sottosistema AFALG, la syscall splice() e la gestione della page cache. Il risultato è una scrittura controllata nella page cache del kernel, aggirando completamente i normali percorsi del filesystem.
E qui arriva il dettaglio che rende Copy Fail davvero pericoloso: la page cache è la copia in memoria dei file su disco. Alterare quei dati equivale, dal punto di vista dell’esecuzione, a modificare direttamente un file binario, ma senza lasciare tracce persistenti sul disco. Un’analisi forense sull’immagine del disco non rivelerebbe nulla di anomalo. Solo strumenti in grado di leggere la cache in tempo reale potrebbero intercettare la modifica.
Distribuzioni colpite e patch disponibili per Copy Fail
I test hanno confermato il comportamento su distribuzioni come Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 e SUSE 16. Il dato più significativo è proprio l’assenza totale di adattamenti necessari: lo stesso identico script funziona ovunque. Si parla di un exploit con affidabilità prossima al 100%, eseguito in un singolo tentativo.
La correzione ufficiale elimina l’ottimizzazione introdotta nel 2017 e ripristina la separazione tra buffer di input e output nelle operazioni AEAD. Il commit correttivo, identificato come a664bf3d603d, è già integrato nelle versioni aggiornate del kernel distribuite dai principali vendor.
Per chi non può aggiornare subito, esiste una mitigazione efficace: disabilitare il modulo algifaead. Nella maggior parte dei sistemi questa scelta non ha alcun impatto reale, perché le librerie crittografiche più diffuse, come OpenSSL o GnuTLS, non utilizzano AFALG in configurazione standard. Negli ambienti dove viene eseguito codice non affidabile, è poi consigliabile bloccare la creazione di socket AFALG tramite seccomp, un meccanismo di sicurezza che limita le chiamate di sistema consentite ai processi. Una misura semplice ma molto efficace.
Cosa distingue Copy Fail dalle vulnerabilità storiche di Linux
Va chiarito un punto importante: Copy Fail non offre accesso remoto diretto. Serve un punto di ingresso locale, che siano credenziali compromesse, accesso SSH oppure una vulnerabilità applicativa che consenta l’esecuzione di codice. Nella pratica, però, questa condizione è tutt’altro che rara nelle catene di attacco reali.
Il confronto con bug storici come Dirty COW o Dirty Pipe è illuminante. Nel caso di Copy Fail manca completamente la componente di race condition. Non servono tentativi multipli, non servono sincronizzazioni delicate. Il comportamento è deterministico: o funziona al primo colpo, o non funziona affatto. Per quanto riguarda la rilevabilità, gli strumenti di integrity checking possono intercettare la modifica solo finché la pagina resta in cache.
Il codice coinvolto esisteva da anni. La vulnerabilità è rimasta del tutto invisibile fino a un’analisi mirata del sottosistema crittografico, a dimostrazione di quanto una singola ottimizzazione apparentemente innocua possa introdurre effetti collaterali profondi.