PoC DirtyDecrypt Linux: rischio LPE per chi non ha patchato
Disponibile il PoC di DirtyDecrypt, LPE nel kernel Linux per sistemi con CONFIG_RXGK. Chi usa AFS deve verificare subito la patch del 25 aprile.
Contenuto
Il team di sicurezza V12 ha pubblicato oggi, 18 maggio 2026, un proof-of-concept exploit per una vulnerabilità di local privilege escalation nel modulo rxgk del kernel Linux, soprannominata DirtyDecrypt. La segnalazione autonoma inviata il 9 maggio è stata riconosciuta dai maintainer del mainline come duplicato di un difetto già corretto il 25 aprile. La disponibilità del codice dimostrativo, tuttavia, trasforma il bug da una voce di changeling in una minaccia concreta per i sistemi con CONFIG_RXGK attivo che non hanno ancora ricevuto l'aggiornamento.
- Il PoC sfrutta una pagecache write priva di COW guard nella funzione rxgk_decrypt_skb del modulo rxgk.
- La segnalazione del team V12 è del 9 maggio, ma il bug risulta già patchato nel kernel mainline dal 25 aprile 2026 secondo l'analista Will Dormann.
- Non esiste un CVE ID ufficiale associato alla segnalazione duplicata; Dormann ipotizza la corrispondenza con CVE-2026-31635.
- La superficie di attacco è ristretta ai sistemi compilati con CONFIG_RXGK attiva, necessaria per il supporto RxGK del client AFS.
Il duplicato di maggio che riporta il rischio ad aprile
La cronaca tecnica inizia il 9 maggio, quando il team V12 invia autonomamente la segnalazione ai maintainer del kernel. La risposta è immediata: il problema era già noto e la correzione era stata integrata nel mainline il 25 aprile 2026. Secondo l'analista Will Dormann, i dettagli forniti da V12 corrispondono a quelli di CVE-2026-31635, anche se alla segnalazione duplicata non è stato assegnato un CVE ID ufficiale distinto.
La mancanza di un identificatore ufficiale per la segnalazione V12 introduce un elemento di confusione nei processi di gestione delle vulnerabilità. Molte aziende filtrano gli alert per CVE ID; se il bug non ne ottiene uno autonomo, il rischio di sottovalutare la priorità è concreto, specialmente dove i team di sicurezza non monitorano direttamente i commit del kernel mainline. L'orientamento di Dormann offre un punto di riferimento, ma rimane un'opinione di analista fino a eventuale conferma formale.
Ciò che cambia il quadro è l'uscita del PoC. Fino al 18 maggio il rischio rimaneva teorico per chi aveva già patchato; da oggi diventa una scadenza operativa per chi non lo ha fatto. La disponibilità di codice funzionante abbassa la barriera all'ingresso per chi cerca di sfruttare il difetto su sistemi non aggiornati, spostando la priorità dalla segnalazione alla remediation.
"We found and reported this on May 9, 2026, but was informed it was a duplicate by the maintainers"
— V12 security team
Il meccanismo nel modulo rxgk
Il nucleo del difetto risiede in una pagecache write che avviene senza il necessario COW (Copy-On-Write) guard all'interno della funzione rxgk_decrypt_skb. Questa mancanza consente a un attaccante già presente sul sistema di manipolare la memoria condivisa e innescare una escalation dei privilegi fino a root. La condizione è strettamente legata al modulo rxgk, che fornisce il supporto RxGK per il client Andrew File System (AFS).
La compromissione richiede un accesso locale preliminare: l'attaccante deve già disporre di una shell o di un punto d'appoggio sulla macchina. Da questa posizione, l'exploit manipola la pagecache attraverso la funzione vulnerabile, bypassando i controlli di isolamento della memoria e ottenendo privilegi di root. Il vettore è quindi un amplificatore di minaccia piuttosto che una porta di ingresso, ma la sua pericolosità non è inferiore: una volta eseguito, l'attaccante ottiene il controllo completo del sistema, compromettendo ogni meccanismo di sicurezza basato sulla separazione dei privilegi.
Perché la data della patch non basta a chiudere il rischio
La correzione del 25 aprile nel mainline Linux è indiscutibile sul piano tecnico, ma la sua efficacia dipende interamente dalla catena di distribuzione. I vendor di sistemi operativi devono integrare il commit nei propri repository, ricompilare i pacchetti e renderli disponibili agli utenti. Su alcune rolling release questo ciclo è breve, mentre su build custom o su ambienti isolati la latenza può allungarsi significativamente. Il PoC pubblico oggi elimina ogni margine: chiunque abbia un kernel con CONFIG_RXGK e non abbia ricevuto l'update effettivo è potenzialmente a rischio di escalation.
Superficie di attacco ristretta, ma non trascurabile
Non ogni installazione Linux è esposta. L'exploit funziona esclusivamente sui kernel compilati con l'opzione CONFIG_RXGK abilitata, una configurazione non universale. Il PoC del team V12 è stato testato solo su Fedora e sul kernel mainline; non è verificato, al momento, che il codice produca lo stesso effetto su Arch Linux o openSUSE Tumbleweed, anche se la logica suggerisce che le rolling release con AFS e RxGK potrebbero essere affette se non aggiornate.
Al contrario, le piattaforme enterprise che si affidano a kernel LTS personalizzati potrebbero non includere affatto il modulo rxgk nelle configurazioni predefinite, riducendo drasticamente il perimetro. L'incognita maggiore riguarda i sistemi custom o i build interni dove la visibilità sulle opzioni di compilazione è frammentaria. Le distribuzioni rolling release rappresentano il profilo più a rischio, poiché integrano rapidamente il kernel mainline ma richiedono all'utente o all'amministratore di mantenere attivo il flusso degli aggiornamenti.
Un sistema Fedora aggiornato dopo il 25 aprile dovrebbe essere protetto; uno lasciato indietro, invece, è ora esposto a un exploit pubblico e verificato. La sfida principale per i team di sicurezza è proprio questa: mappare la propria postura di compilazione senza assumere che la patch sia l'unica variabile che conta.
Cosa fare adesso
Le azioni prioritarie per ridurre il rischio partono tutte dalla verifica della configurazione, non solo dalla versione del kernel.
- Verificare se il kernel in uso include il modulo rxgk e se l'opzione CONFIG_RXGK è attiva; se sì, confermare che la patch integrata il 25 aprile 2026 sia presente nell'ambiente di produzione.
- Su sistemi dove l'update non è immediato, applicare la mitigazione temporanea che consiste nel bloccare i moduli del kernel esp4, esp6 e rxrpc, consapevoli che questa azione interromperà le connessioni IPsec VPN e l'accesso ai filesystem AFS distribuiti.
- Auditare gli endpoint per verificare se il modulo rxgk è caricato e se il sistema utilizza effettivamente il client AFS con RxGK, calibrando la priorità dell'intervento sulla base dell'esposizione reale.
- Aggiornare le policy di vulnerability management per tracciare l'eventuale assegnazione di un CVE ID ufficiale alla segnalazione V12, allineando le procedure interne alla nomenclatura definitiva del bug.
L'episodio di DirtyDecrypt conferma che il tempo tra patch e exploit pubblico si sta comprimendo ulteriormente, anche quando il bug è tecnicamente noto da settimane. Le aziende che gestiscono flotte eterogenee devono fare i conti con una verità scomoda: la correzione nel codice sorgente non equivale alla protezione del sistema operativo in esecuzione. In questo caso specifico, la limitazione della superficie di attacco offre un margine, ma solo a chi sa con certezza cosa gira sui propri server.
Domande frequenti
Ho aggiornato il kernel dopo il 25 aprile, devo preoccuparmi?
Se la patch di mainline è inclusa nella build distribuita dal vendor e utilizzi il modulo RxGK per AFS, la correzione dovrebbe essere efficace. Verifica comunque la presenza specifica dell'update e conferma che CONFIG_RXGK non sia attivo se non necessario.
Il PoC è pericoloso anche per server senza AFS?
No. Il modulo rxgk è strettamente necessario. Se CONFIG_RXGK non è abilitato nella configurazione di compilazione o il modulo non è caricato, il sistema non è raggiungibile attraverso questo vettore specifico.
Perché non c'è un CVE ufficiale per DirtyDecrypt?
I maintainer del kernel hanno classificato la segnalazione V12 come duplicato. Senza una segnalazione indipendente accettata come nuova, non viene generato un CVE ID distinto, anche se l'analista Will Dormann ha proposto un collegamento con CVE-2026-31635.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.