L’AI trova zero-day Linux, ma l’exploit resta nelle mani del ricercatore

🛡️ Executive Summary

• Un ricercatore di STAR Labs ha usato l’AI per individuare una use-after-free nel sottosistema net/sched del kernel Linux.
• L’exploit locale sviluppato per CentOS Stream 9 ottiene privilegi root in pochi secondi, ma richiede condizioni e adattamenti specifici.
• L’AI ha accelerato ricerca, proof of concept e ottimizzazione della race condition, senza sostituire il giudizio tecnico umano.

Un ricercatore di STAR Labs ha utilizzato strumenti di intelligenza artificiale per individuare una vulnerabilità zero-day nel kernel Linux e trasformarla in un exploit locale capace di ottenere privilegi root su CentOS Stream 9. La falla, successivamente identificata come CVE-2026-53264, è una use-after-free nel sottosistema di gestione del traffico di rete net/sched. L’AI ha contribuito alla scoperta del bug, alla creazione del proof of concept KASAN e all’ottimizzazione della race condition, ma non ha sviluppato autonomamente l’intera catena. Il ricercatore ha dovuto ricostruire i vincoli del kernel, perfezionare il memory reclaim e adattare manualmente l’exploit al sistema bersaglio.

L’AI individua una race condition nel kernel Linux

La vulnerabilità si trova nel sottosistema net/sched, utilizzato dal kernel Linux per gestire code, filtri e azioni applicate ai pacchetti di rete. Il problema nasce da una mancata corrispondenza tra i meccanismi di sincronizzazione: la funzione tcf_idr_check_alloc() legge un oggetto tc_action sotto la protezione di RCU, mentre un altro thread può eliminarlo usando lock differenti e liberarne immediatamente la memoria senza attendere il completamento del periodo di grazia RCU. In una finestra temporale molto ridotta, un thread può quindi recuperare il puntatore a un’azione, un secondo thread può liberare l’oggetto e un terzo può riutilizzare la stessa area di memoria prima dell’incremento del contatore dei riferimenti. Il risultato è una use-after-free sfruttabile localmente. L’AI ha aiutato il ricercatore a riconoscere questo schema e a costruire rapidamente un proof of concept capace di provocare l’errore sotto KASAN, avvicinando la ricerca di una falla inedita al ritmo normalmente associato all’analisi di una vulnerabilità già documentata. Il caso si inserisce nella crescente applicazione dei modelli alla ricerca automatizzata, già evidente quando Kimi K3 ha individuato uno zero-day in Redis e altre falle in NodeBB, ma mostra anche quanto la segnalazione iniziale sia distante da un exploit completo.

La falla richiede namespace utente e componenti specifici

Lo sfruttamento non è universale e dipende da diverse condizioni del sistema. Per raggiungere il percorso vulnerabile senza privilegi iniziali è necessario che il kernel consenta la creazione di user namespace non privilegiati, attraverso i quali l’utente locale può ottenere CAP_NET_ADMIN all’interno di un nuovo namespace di rete. Il sistema deve inoltre includere il supporto per le azioni gact e per il classificatore flower, normalmente associati alle configurazioni CONFIG_NET_ACT_GACT e CONFIG_NET_CLS_FLOWER. Il ricercatore ha escluso l’impiego diretto delle operazioni RTM_NEWACTION e RTM_DELACTION, perché richiedono privilegi amministrativi nel namespace iniziale, e ha raggiunto il codice vulnerabile attraverso la creazione e la cancellazione di filtri Netlink. La configurazione utilizza una queueing discipline clsact e filtri flower per evitare il lock globale rtnl_lock, condizione necessaria a mantenere aperta la finestra della race. Questi vincoli limitano la superficie rispetto a una RCE remota, ma non riducono il valore della falla nei desktop Linux e negli ambienti nei quali un aggressore ha già ottenuto l’esecuzione di codice con un account ordinario. La precedente analisi di Bad Epoll nel kernel Linux aveva già mostrato come una vulnerabilità locale nella gestione della memoria possa diventare il passaggio decisivo per trasformare un accesso limitato in controllo root.

La race passa da quindici minuti a cinque secondi

Il primo tentativo richiedeva oltre quindici minuti per colpire la finestra vulnerabile, rendendo l’exploit poco affidabile per una competizione. Il ricercatore ha quindi applicato una tecnica basata su timerfd ed epoll per rallentare temporaneamente il thread che esegue il lookup dell’azione, aumentando il tempo disponibile per liberare e rioccupare la memoria. Ha inoltre separato i thread su catene differenti, evitando la contesa sullo stesso mutex, e ristrutturato l’intera race sfruttando un percorso di errore nella creazione dei filtri. I binder thread inviano una richiesta contenente una prima azione valida e una seconda deliberatamente malformata: il kernel recupera l’oggetto bersaglio, ma interrompe la creazione prima dell’inserimento definitivo del filtro. Un singolo deleter thread crea ed elimina ripetutamente l’azione con lo stesso indice, mentre più binder competono per accedervi. Questa configurazione ha ridotto il tempo necessario per attivare la use-after-free a circa cinque secondi. L’AI ha contribuito all’iterazione e all’ottimizzazione, ma la scelta dei percorsi Netlink, la riduzione dell’overhead e la costruzione della sincronizzazione sono rimaste attività guidate dal ricercatore.

Il memory reclaim porta al controllo del kernel

Dopo aver liberato l’oggetto tc_action, l’exploit deve rioccupare la stessa area della cache kmalloc-256 con dati controllabili. Il ricercatore ha utilizzato oggetti user_key_payload, creati e aggiornati attraverso KEYCTL_UPDATE, perché la loro struttura consente di sovrascrivere campi cruciali dell’oggetto eliminato, compreso il puntatore alla tabella delle operazioni. La gestione RCU delle chiavi permette di creare una successione di payload collegati e controllare indirettamente il flusso di esecuzione quando il kernel tenta di invocare una funzione virtuale dell’azione ormai sostituita. Dopo aver ottenuto il controllo del registro delle istruzioni, la catena effettua uno stack pivot verso un’area contenente una sequenza ROP e modifica core_pattern. Linux viene quindi indotto a eseguire come root un file memfd controllato dall’utente nel momento in cui un processo provoca intenzionalmente un crash. L’exploit finale utilizza offset ROP specifici per il kernel di CentOS e non è immediatamente portabile su ogni distribuzione: versioni successive cambiano registri, gadget e disposizione delle funzioni, obbligando a riscrivere parti della catena. Questo limite è importante perché distingue la scoperta automatizzata di un bug dalla produzione di un exploit affidabile e generalizzabile.

CentOS Stream 9 viene compromesso in pochi secondi

L’exploit è stato sviluppato per la categoria Linux Local Privilege Escalation della competizione TyphoonPwn 2026 e testato su un computer con CentOS Stream 9. Dieci esecuzioni consecutive hanno ottenuto privilegi root in tutti i casi, con tempi variabili: diversi tentativi si sono conclusi tra nove e undici secondi, mentre altri hanno richiesto da 47 a 111 secondi, probabilmente per il throttling termico della CPU. Il ricercatore non ha potuto presentare materialmente l’exploit durante la competizione perché era ottavo nella coda di esecuzione e i tre premi disponibili erano già stati assegnati prima del proprio turno.

Pochi giorni dopo ha inoltre scoperto che lo stesso bug era stato segnalato da un altro ricercatore due giorni prima dell’evento. La vulnerabilità è stata quindi assegnata come CVE-2026-53264 e corretta nel kernel Linux. Il dettaglio ridimensiona la definizione commerciale di “zero-day scoperto dall’AI”: la falla era inedita quando venne trovata in modo indipendente, ma il ricercatore non fu il primo a comunicarla al progetto Linux.

Altre due falle emergono durante la stessa ricerca

La sperimentazione ha portato all’individuazione di altri due problemi sfruttabili in kernel/events/core.c, entrambi legati al sottosistema perf e raggiungibili principalmente su sistemi Intel bare metal con perf_event_paranoid impostato a un valore non superiore a 2. Il primo produce una primitive di scrittura attraverso una use-after-free, ma risulta difficile da controllare perché sovrascrive gran parte dell’oggetto coinvolto. Il secondo consente una page use-after-free più potente ed è stato trasformato rapidamente in un exploit LPE affidabile, testato anche su Arch Linux con kernel 7.0.12. Questa seconda vulnerabilità è stata registrata come CVE-2026-64300.

La superficie è meno significativa negli ambienti cloud, perché le macchine virtuali normalmente non permettono l’accesso diretto alla PMU Intel Processor Trace richiesta dal percorso vulnerabile, ma resta rilevante per workstation e desktop Linux. L’emersione di più falle durante la stessa attività suggerisce che l’AI possa essere particolarmente efficace nel cercare schemi ripetuti, come accessi RCU seguiti da liberazioni non differite, una volta che il ricercatore ha definito una categoria tecnica precisa da esplorare.

L’AI accelera la ricerca ma conserva punti ciechi

L’aspetto più rilevante del report non consiste nell’affermazione che l’intelligenza artificiale possa sostituire un exploit developer. Lo stesso autore riconosce che i modelli hanno mostrato lacune di ragionamento, punti ciechi e difficoltà nel comprendere completamente le interazioni interne del kernel. Il loro valore è emerso soprattutto nella velocità: generazione di ipotesi, ricerca di pattern sospetti, produzione del KASAN proof of concept e modifica ripetuta del codice della race. La validazione delle risposte, la selezione dei percorsi raggiungibili da un utente non privilegiato e la trasformazione della use-after-free in primitive sfruttabili hanno richiesto esperienza diretta. Questa distinzione è essenziale anche alla luce della decisione di Linus Torvalds di rivedere i report di sicurezza Linux dopo l’aumento delle segnalazioni duplicate prodotte con l’AI. Un modello può aumentare enormemente il numero di potenziali bug sottoposti ai manutentori, ma può anche generare rumore, duplicati e interpretazioni errate se chi lo utilizza non è in grado di verificare il codice e delimitare la reale sfruttabilità.

Gli zero-day iniziano ad assomigliare agli n-day

Nella ricerca tecnica di STAR Labs sull’exploit del kernel Linux, il titolo descrive un cambiamento metodologico più che una completa automazione offensiva. Tradizionalmente, lo studio di uno zero-day richiede prima di comprendere in profondità un sottosistema, individuare un’incoerenza e solo successivamente costruire il proof of concept. In questo caso l’AI ha anticipato parte del lavoro esplorativo e fornito al ricercatore una falla concreta sulla quale concentrarsi, rendendo il processo simile all’analisi di un n-day già accompagnato da patch, diff e indicazioni sul punto vulnerabile. Il vantaggio può comprimere drasticamente il tempo tra scoperta ed exploit, aumentando la pressione sui progetti open source e sui team di risposta. Non elimina però la necessità di comprendere il target: senza la conoscenza di Netlink, RCU, allocator, keyring, ROP e configurazioni Linux, il bug sarebbe rimasto un crash instabile. L’AI rende più economica la ricerca degli zero-day, ma il passaggio dalla segnalazione al controllo affidabile del kernel resta ancora un lavoro di ingegneria umana altamente specializzata.