Oltre 16,4 milioni di sistemi Linux nel mondo risultano potenzialmente esposti a una vulnerabilità presente nel kernel fin dalla versione 4.11, rilasciata nel 2017. A rivelarlo è la Threat Research Unit di Qualys, che ha ribattezzato la falla RefluXFS, ufficialmente monitorata con la sigla CVE-2026-64600.

La vulnerabilità riguarda il percorso di copy-on-write del filesystem XFS e consente a un utente locale privo di privilegi amministrativi di sovrascrivere il contenuto su disco di qualsiasi file leggibile presente su un volume XFS con reflink attivo, ottenendo di fatto privilegi di root sull'host. La particolarità che rende RefluXFS especialmente insidiosa è la sua natura silenziosa: lo sfruttamento non lascia alcuna traccia nei log del kernel e la modifica al file system sopravvive al riavvio del sistema.

Il team di ricerca Qualys l’ha scoperta nell'ambito del progetto Glasswing di Anthropic, integrando Claude Mythos Preview nel proprio flusso di audit manuale con l'obiettivo di individuare condizioni di race simili a quella storica di Dirty COW. Dopo diverse iterazioni di affinamento dei prompt, mirate a concentrare l'analisi del modello sulle directory core di gestione della memoria e del filesystem, Claude Mythos Preview ha isolato la race condition in XFS e generato un proof of concept funzionante per l'escalation locale dei privilegi. I ricercatori umani hanno quindi verificato il ragionamento del modello, riprodotto in autonomia l'exploit e validato ogni claim tecnico prima di pubblicare i risultati dell’indagine.

Come funziona la race condition

Il meccanismo si comprende meglio seguendo la sequenza degli eventi. Il file bersaglio è reflinked, cioè condivide fisicamente i propri blocchi su disco con un'altra copia. È una tecnica che XFS usa per risparmiare spazio evitando di duplicare dati identici. Quando un processo scrive su un file di questo tipo in modalità O_DIRECT (cioè scrivendo direttamente sul disco senza passare dalla cache del kernel), XFS deve prima "scollegare" quel blocco dalla copia condivisa: crea una copia privata del blocco, aggiorna il file perché punti a questa nuova copia, e riduce di uno il conteggio di quante copie condividono ancora il blocco originale. Questo procedimento si chiama copy-on-write.

Il problema scaturisce da un dettaglio operativo. Durante l'attesa necessaria a completare l'operazione, il kernel rilascia temporaneamente il lock che protegge il file, per evitare che il sistema si blocchi (deadlock). È esattamente in questo intervallo di tempo, apparentemente innocuo, che si apre la finestra di attacco: se in quel preciso istante un secondo processo esegue la stessa operazione di scrittura sullo stesso file, riesce a completare il proprio ciclo di copy-on-write per primo, riportando il conteggio delle copie condivise a uno.

Quando il primo processo riprende il controllo, va a verificare quel conteggio, ma lo fa basandosi su un'informazione ormai superata, cioè l'indirizzo del blocco che aveva registrato prima di perdere il lock. Trovando un conteggio pari a uno, il kernel conclude, erroneamente, che il blocco sia ormai di uso esclusivo del primo processo, e quindi sicuro da sovrascrivere direttamente. In realtà quel blocco è già stato riassegnato dal secondo processo. Il risultato è che il primo processo scrive sopra al file originale e quella scrittura indesiderata viene salvata su disco in modo permanente.

Nel proof of concept dimostrato da Qualys su un'installazione predefinita di RHEL 10.2, un utente locale privo di diritti amministrativi ha sfruttato la race condition per sovrascrivere silenziosamente un file di sistema protetto a livello di blocco. Nel giro di pochi secondi la protezione della password dell'account root è stata rimossa, così da garantire un accesso root immediato e senza password. La modifica persiste dopo il riavvio e non genera alcun artefatto nei log del kernel.

Sistemi coinvolti e mitigazioni

Affinché un sistema risulti vulnerabile devono ricorrere contemporaneamente tre condizioni: l'esecuzione di un kernel Linux dalla versione 4.11 in poi privo della patch specifica, l'utilizzo di un filesystem XFS con reflink attivo nel superblocco, e la presenza sul filesystem sia di un target ad alto valore, come un file di configurazione root o un binario SUID-root, sia di una directory scrivibile da un utente locale non privilegiato.

La falla è presente in ogni kernel mainline e stabile rilasciato dal 2017 e non richiede capability speciali né configurazioni non standard. Tra le distribuzioni confermate come vulnerabili figurano RHEL nelle versioni 8, 9 e 10, CentOS Stream 8, 9 e 10, Oracle Linux 8, 9 e 10, Rocky Linux e AlmaLinux nelle stesse versioni, CloudLinux 8, 9 e 10, le immagini Amazon Linux 2023 e Amazon Linux 2 rilasciate da dicembre 2022 in avanti, e Fedora Server dalla versione 31. Qualys precisa che l'elenco non è esaustivo e che altre distribuzioni, in particolare quelle derivate da RHEL, sono probabilmente esposte allo stesso modo. Debian, Ubuntu e SUSE non utilizzano XFS come filesystem predefinito, ma diventano vulnerabili se un amministratore seleziona manualmente XFS in fase di installazione con reflink attivo.

Le difese comuni non intercettano RefluXFS perché la falla agisce a livello del layer di allocazione del filesystem, al di sotto o al di fuori del perimetro presidiato dalla maggior parte delle protezioni di sistema. Nei test condotti da Qualys, SELinux non blocca il percorso interessato dalla vulnerabilità, nemmeno in modalità Enforcing, e anche i meccanismi di isolamento tipici degli ambienti containerizzati non intervengono perché operano su livelli che la vulnerabilità non tocca mai. Sfruttando il normale meccanismo di allocazione del filesystem, RefluXFS elude quindi le difese progettate per presidiare memoria, system call e confini di privilegio.

Al momento non esistono mitigazioni pratiche o modifiche di configurazione temporanee in grado di neutralizzare il rischio: l'unica contromisura affidabile è l'applicazione immediata della patch del kernel seguita da un riavvio del sistema per verificarne l'effettiva installazione. I kernel corretti dai vendor sono già disponibili e in fase di backport sulle distribuzioni enterprise. Qualys raccomanda alle organizzazioni di dare priorità al patching dei sistemi esposti e multi-tenant, assicurandosi di completare il riavvio necessario a rendere effettiva la correzione.