SCTPhantom è il bug del 2008 che concede permessi root sul kernel Linux

Il 3 agosto i kernel stabili 7.1.6, 6.18.42, 6.12.101 e 6.6.148 hanno chiuso una use-after-free nel codice SCTP di Linux che consente a un utente locale di ottenere i privilegi di root sulla macchina. La falla, tracciata come CVE-2026-64564 e battezzata SCTPhantom da chi l'ha trovata, risale a Linux 2.6.25, cioè al 2008, ed è stata presente in ogni kernel rilasciato da allora.

La falla è stata individuata presso Tencent Zhuque Lab, che attribuisce la scoperta a Corvus AI, una pipeline di ricerca multi-agente costruita internamente per il lavoro sul kernel. Il laboratorio dichiara di aver ottenuto root sui kernel provati per Debian 13, Ubuntu 24.04, Rocky Linux 9 e RHEL 9 e OpenCloudOS, e di essere risalito da un container fino alla macchina sottostante. Nel test di evasione, riferisce, il profilo seccomp era quello predefinito e non erano concesse né CAP_NET_ADMIN né CAP_SYS_ADMIN: sei tentativi su otto hanno raggiunto root sull'host. SCTPhantom è l'ultima di una serie di falle del kernel rimaste dormienti a lungo e riemerse quest'anno con assistenza automatica, dopo GhostLock a luglio.

Il controllo cade su un indirizzo, l'azione su un altro

SCTP è un protocollo di trasporto che permette a una singola connessione di viaggiare su più percorsi di rete contemporaneamente. Una funzione collegata, la riconfigurazione dinamica degli indirizzi, consente a un peer di aggiungere o rimuovere quegli indirizzi a connessione già avviata, attraverso messaggi ASCONF.

L'avviso del kernel descrive quello che è a tutti gli effetti uno scambio di identità. La funzione sctp_process_asconf() conserva il transport contro cui il messaggio viene elaborato; quando l'associazione è individuata attraverso il parametro di indirizzo contenuto nel messaggio, quel transport corrisponde al parametro e non deve necessariamente coincidere con l'indirizzo sorgente del pacchetto. Il codice rifiuta la cancellazione dell'indirizzo sorgente, come previsto dalla clausola D8 di ADDIP, mentre nulla protegge il transport messo da parte.

Un singolo ASCONF può quindi contenere, nell'ordine, un parametro di indirizzo L diverso dal sorgente, una richiesta di cancellazione per L e una cancellazione con indirizzo jolly 0.0.0.0. La prima cancellazione supera il controllo e libera il transport, la seconda lo riusa quando la memoria è già stata rilasciata.

Da lì l'associazione resta con i puntatori primary_path e active_path rivolti a memoria liberata, e la rimozione dei peer non primari elimina tutti i transport reali tenendo solo quello che non è più in lista, lasciando un conteggio a zero. La correzione rifiuta le cancellazioni dirette al transport contro cui l'ASCONF viene elaborato, replicando la protezione che già esisteva per l'indirizzo sorgente.

Serve un accesso locale e SCTP raggiungibile

Lo sfruttamento richiede un accesso locale e la raggiungibilità di SCTP sul bersaglio, condizione che restringe parecchio l'esposizione reale. Nel resoconto del laboratorio, una prima versione dell'exploit richiedeva l'attivazione dei parametri net.sctp.addip_enable e net.sctp.addip_noauth_enable, il che faceva sembrare CAP_NET_ADMIN un prerequisito; una via individuata in seguito abilita le stesse funzioni per singolo socket e lascia entrambi i parametri intatti.

Nessuno all'esterno del laboratorio ha finora replicato l'evasione dal container, e il resoconto non nomina il runtime su cui è stata provata. Lo stesso laboratorio osserva che l'accesso ai socket, i profili seccomp e le politiche sui namespace utente spostano l'esposizione da un sistema all'altro. Un avviso di openKylin sulla stessa falla si ferma al kernel panic e al denial of service.

Anche il peso assegnato alla vulnerabilità è tutt'altro che assestato. Tencent le ha attribuito 8.5 su scala CVSS 4.0, mentre il NIST non ha ancora pubblicato né un punteggio proprio né una classificazione della debolezza. La divulgazione pubblica è del 6 agosto, due giorni dopo l'assegnazione del CVE da parte del team del kernel; al 7 agosto la falla non risultava nel catalogo Known Exploited Vulnerabilities della CISA e non risultava pubblico alcun codice di sfruttamento.

Per chi amministra sistemi la stringa di versione del kernel non basta a stabilire se si è coperti, perché le distribuzioni integrano spesso le correzioni senza allinearsi alla versione upstream: il riferimento è il bollettino di sicurezza della propria distribuzione. Una seconda use-after-free sullo stesso tipo di transport pendente, nello stesso codice, è stata corretta il 6 agosto, dopo l'uscita dei kernel stabili del 3, che quindi non la contengono. Dove SCTP non serve, bloccare il modulo elimina del tutto la superficie di attacco.