RefluXFS minaccia milioni di server Linux: come ottenere root

La vulnerabilità CVE-2026-64600 colpisce i sistemi Linux con file system XFS: un utente locale può alterare file protetti e ottenere accesso root. La falla risale a Linux 4.11 e richiede l'aggiornamento del kernel.

Una vulnerabilità rimasta nel kernel Linux per circa 9 anni permette a un utente locale senza privilegi amministrativi di modificare file protetti e ottenere accesso root. La falla, identificata come CVE-2026-64600 e battezzata RefluXFS, interessa il filesystem XFS quando la funzione reflink risulta attiva. Non serve sfruttare un errore di memoria, caricare moduli o disporre di abilità particolari: l’attacco usa normali operazioni di clonazione e scrittura su file, ma riesce a confondere il meccanismo copy-on-write del kernel.

Il problema risale a Linux 4.11, pubblicato nel 2017, ed è quindi entrato in numerose generazioni del kernel. Gli ingegneri di Qualys, che hanno individuato la vulnerabilità, stimano una superficie potenziale superiore a 16,4 milioni di sistemi. Il dato non equivale al numero di macchine certamente sfruttabili, perché servono alcune condizioni precise; resta però indicativo della diffusione di XFS nei server aziendali, nelle infrastrutture cloud e nelle distribuzioni derivate da Red Hat.

RefluXFS merita attenzione soprattutto per tre ragioni: l’exploit può risultare molto affidabile, la modifica viene scritta direttamente sul disco e il kernel non produce necessariamente messaggi di errore o avvisi in dmesg. Un riavvio non ripristina il file originale; anzi, senza un controllo esplicito dell’integrità, l’amministratore potrebbe non accorgersi subito dell’alterazione.

Quali sistemi Linux sono esposti a RefluXFS

Come anticipato in precedenza, la presenza di un kernel successivo alla versione 4.11, da sola, non basta a rendere vulnerabile un sistema. RefluXFS richiede un volume XFS con reflink abilitato, un file leggibile d’interesse per l’attaccante e almeno una directory scrivibile da un utente sprovvisto di privilegi sullo stesso filesystem.

Una tipica installazione server soddisfa facilmente l’ultima condizione. La directory /var/tmp, per esempio, consente normalmente la scrittura agli utenti locali e spesso si trova sullo stesso volume di /etc e /usr/bin. In un altro articolo abbiamo illustrato la struttura del filesystem su Linux.

L’attaccante può quindi creare il proprio file temporaneo accanto, dal punto di vista del filesystem, a configurazioni appartenenti a root o a programmi con bit SUID.

Secondo l’analisi di Qualys, risultano particolarmente esposte le installazioni predefinite di RHEL 8, 9 e 10, CentOS Stream, Rocky Linux, AlmaLinux, Oracle Linux, CloudLinux, Fedora Server dalla versione 31 e Amazon Linux. Il problema può comunque riguardare anche Debian, Ubuntu, SUSE, openSUSE o Arch Linux quando l’amministratore ha scelto manualmente XFS e il volume è stato creato con reflink attivo.

Per controllare il filesystem radice si può eseguire quanto segue: xfs_info / | grep reflink

Se il comando restituisce reflink=1, il volume supporta la clonazione copy-on-write coinvolta nella vulnerabilità.

Ti propongo una versione molto più compatta, che conserva solo meccanismo, impatto e rimedio.

Come funziona l’attacco RefluXFS

RefluXFS sfrutta una race condition nel meccanismo copy-on-write di XFS. In pratica, due operazioni concorrenti modificano quasi nello stesso momento un file clonato tramite reflink; il kernel può usare informazioni ormai superate e indirizzare la scrittura verso il file originale anziché verso la copia.

L’attaccante parte da un file di sistema leggibile, ne crea un clone su una directory scrivibile dello stesso filesystem e avvia più scritture simultanee. Se la sincronizzazione riesce, i dati destinati al clone finiscono nel file protetto appartenente a root. Da qui il nome RefluXFS: la modifica sembra “tornare indietro” dalla copia all’originale.

Un utente locale può sfruttare il difetto per alterare file importanti, come configurazioni degli account o programmi eseguiti con privilegi elevati. La modifica interessa direttamente i dati memorizzati sul disco, mentre proprietario, permessi e timestamp possono restare invariati; alcuni controlli basati soltanto sui metadati rischiano quindi di non rilevarla.

La vulnerabilità non consente un attacco remoto diretto. Serve già un accesso locale al sistema, ma su server condivisi, piattaforme di hosting, runner CI e macchine che eseguono codice non attendibile può trasformare rapidamente un account limitato nel controllo completo dell’host.

La priorità per gli amministratori

RefluXFS non espone automaticamente ogni server Linux collegato a Internet. Il problema di sicurezza diventa però critico quando utenti o applicazioni non affidabili possono operare su un filesystem XFS vulnerabile.

Gli amministratori devono quindi verificare l’uso di reflink, applicare l’aggiornamento integrato a livello della singola distribuzione Linux, riavviare e controllare l’integrità dei sistemi già esposti.

I tecnici di Qualys spiegano di aver individuato la vulnerabilità durante una ricerca assistita da Claude Mythos Preview, usato per analizzare il codice del kernel e cercare race condition simili ad altre vulnerabilità note. I ricercatori hanno poi verificato manualmente il difetto, sviluppato il proof-of-concept e coordinato la correzione con i manutentori Linux.

SELinux e altre protezioni possono impedire a un processo di scrivere direttamente su un file protetto. In questo caso, però, l’utente modifica un clone di sua proprietà ed è il kernel, a causa dell’errore, a scrivere nel blocco sbagliato. Anche le difese contro gli exploit di memoria, come KASLR, SMEP e SMAP, non possono affrontare problematiche come RefluXFS.

Ti consigliamo anche

Link copiato negli appunti