RefluXFS è il nome dato a una vulnerabilità che ha dormito nel kernel Linux per quasi nove anni e che oggi permette a un utente locale, senza alcun privilegio amministrativo, di modificare file protetti e arrivare fino all’accesso root. La falla è stata catalogata come CVE-2026-64600 e colpisce il filesystem XFS nel momento in cui la funzione reflink è attiva. Non c’è bisogno di sfruttare errori di memoria, caricare moduli o mettere in campo competenze fuori dal comune. Bastano normali operazioni di clonazione e scrittura sui file, che però riescono a mandare in confusione il meccanismo copy-on-write del kernel.
Il difetto affonda le radici in Linux 4.11, uscito nel 2017, e da lì si è portato dietro in diverse generazioni del kernel. Gli ingegneri di Qualys, che hanno scovato il problema, parlano di una superficie potenziale superiore a 16,4 milioni di sistemi. Un numero che non indica quante macchine siano davvero sfruttabili, perché servono condizioni ben precise, ma che rende l’idea di quanto XFS sia diffuso nei server aziendali, nelle infrastrutture cloud e nelle distribuzioni derivate da Red Hat.
Ci sono tre motivi per cui RefluXFS preoccupa più del solito. L’exploit può risultare parecchio affidabile, la modifica viene scritta direttamente sul disco e il kernel non genera per forza messaggi di errore o avvisi in dmesg. Un riavvio non riporta il file al suo stato originale. Anzi, senza un controllo esplicito dell’integrità, un amministratore potrebbe non accorgersi per giorni di quello che è successo.
Quali sistemi Linux sono davvero esposti
Avere un kernel successivo alla versione 4.11 non basta, da solo, a rendere una macchina vulnerabile. Servono tre elementi contemporaneamente. Un volume XFS con reflink abilitato, un file leggibile che interessi all’attaccante e almeno una directory scrivibile da un utente senza privilegi sullo stesso filesystem.
Una tipica installazione server soddisfa senza fatica l’ultima condizione. La directory /var/tmp, per fare un esempio, di norma è scrivibile dagli utenti locali e spesso si trova sullo stesso volume di /etc e /usr/bin. In questo modo l’attaccante può creare il proprio file temporaneo accanto, dal punto di vista del filesystem, a configurazioni che appartengono a root o a programmi con bit SUID.
Secondo l’analisi di Qualys, le più esposte sono 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. Ma il problema può toccare anche Debian, Ubuntu, SUSE, openSUSE o Arch Linux, quando l’amministratore ha scelto a mano XFS e ha creato il volume con reflink attivo.
Per controllare il filesystem radice basta lanciare xfs_info / | grep reflink. Se il comando restituisce reflink=1, allora il volume supporta la clonazione copy-on-write coinvolta nella falla.
Come funziona l’attacco e cosa devono fare gli amministratori
Alla base di RefluXFS c’è una race condition nel meccanismo copy-on-write di XFS. Detto in modo semplice, due operazioni concorrenti modificano quasi nello stesso istante un file clonato tramite reflink. Il kernel finisce per usare informazioni ormai vecchie e indirizza la scrittura verso il file originale invece che verso la copia.
L’attaccante parte da un file di sistema leggibile, ne crea un clone in una directory scrivibile dello stesso filesystem e avvia più scritture in parallelo. Se la sincronizzazione va a segno, i dati destinati al clone finiscono nel file protetto che appartiene a root. Ecco spiegato il nome: la modifica sembra tornare indietro dalla copia all’originale.
Un utente locale può così alterare file importanti, come le configurazioni degli account o i programmi che girano con privilegi elevati. La modifica tocca direttamente i dati sul disco, mentre proprietario, permessi e timestamp possono restare identici. I controlli basati solo sui metadati rischiano quindi di non accorgersi di nulla.
L’attacco non è remoto. 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 in fretta un account limitato nel controllo completo dell’host.
La vulnerabilità non mette a rischio in automatico ogni server Linux collegato a Internet. Diventa critica quando utenti o applicazioni non affidabili possono operare su un filesystem XFS esposto. Gli amministratori devono quindi verificare l’uso di reflink, applicare l’aggiornamento fornito dalla singola distribuzione Linux, riavviare e controllare l’integrità dei sistemi già colpiti.
I tecnici di Qualys raccontano di aver individuato la falla durante una ricerca assistita da Claude Mythos Preview, usato per analizzare il codice del kernel e cercare race condition simili ad altre già note. Il difetto è stato poi verificato a mano, con tanto di proof-of-concept e correzione coordinata insieme ai manutentori Linux.
C’è un dettaglio che rende RefluXFS particolarmente scivoloso. SELinux e altre protezioni possono impedire a un processo di scrivere direttamente su un file protetto, ma qui l’utente modifica un clone di sua proprietà ed è il kernel, per via dell’errore, a scrivere nel blocco sbagliato. Anche le difese contro gli exploit di memoria, come KASLR, SMEP e SMAP, non hanno alcuna presa su un problema di questo tipo.