Google Project Zero lancia MAccConc: le race condition Linux diventano riproducibili

🛡️ Executive Summary

• Project Zero pubblica MAccConc, toolkit sperimentale per esplorare e forzare interleaving concorrenti nel kernel Linux.
• Traccia accessi memoria con KASAN e KCOV, identifica punti di comunicazione e applica delay injection tramite KCOV_SET_DI.
• LLVM supporta già il requisito principale, ma le patch kernel non sono ancora upstream e il fuzzing automatico resta in sviluppo.

Google Project Zero ha pubblicato MAccConc, acronimo di Memory Access Concurrency, un toolkit sperimentale progettato per affrontare uno dei problemi più ostici nella ricerca di vulnerabilità del kernel Linux: rendere riproducibili le race condition. Il progetto non annuncia una nuova CVE e non richiede aggiornamenti agli utenti finali. Introduce invece una combinazione di tracing degli accessi in memoria, identificatori stabili dello stack e delay injection che consente ai ricercatori di forzare specifici interleaving tra thread, osservare quando due operazioni concorrenti interferiscono e trasformare test probabilistici in esperimenti molto più controllabili. Il funzionamento è descritto nell’analisi tecnica pubblicata da Project Zero.

Perché le race condition sfuggono ai test tradizionali

Le race condition sono difficili da validare perché il comportamento negativo emerge soltanto quando più thread attraversano il codice nel giusto ordine temporale. Jann Horn spiega che, durante l’analisi manuale del kernel, un sospetto può richiedere modifiche ad hoc con delay artificiali e numerosi tentativi prima di essere confermato o escluso. MAccConc parte da questo limite e prova a rendere esplicito il rapporto tra gli accessi concorrenti. Il sistema traccia letture, scritture e liberazioni di memoria, cerca coppie di accessi su thread differenti che insistono su aree sovrapposte e considera interessanti i casi in cui almeno uno dei due effettua una scrittura. Project Zero riprende per questi eventi il concetto di communication points, già utilizzato da ricerche precedenti come SKI, ma evita di dipendere da snapshot completi della macchina virtuale. È una categoria di problemi tutt’altro che teorica: la recente CVE-2026-46242 Bad Epoll ha mostrato come una finestra concorrente estremamente ridotta possa diventare una use-after-free affidabile e portare un processo locale fino ai privilegi root.

KCOV e KASAN trasformano gli accessi memoria in una traccia

Per raccogliere gli accessi, Horn sfrutta l’instrumentation ASAN in modalità outline e la integra con KCOV, il meccanismo del kernel già impiegato per fornire coverage agli strumenti di fuzzing. Nel kernel Linux la configurazione passa attraverso KASAN outline e richiede che l’ottimizzazione capace di fondere callback consecutive venga disabilitata, così da ottenere un evento per ogni accesso rilevante. L’approccio ha limiti dichiarati: ASAN non produce normalmente hook per ogni accesso diretto allo stack e le variabili globali richiedono opzioni specifiche, mentre TSAN offrirebbe informazioni più naturali sulle data race ma non può essere combinato direttamente con ASAN nella toolchain corrente. Proprio il rapporto tra automazione, KASAN e concorrenza è già emerso nella ricerca in cui un sistema AI ha accelerato l’individuazione e l’ottimizzazione di una race condition nel kernel Linux, senza però sostituire il lavoro necessario per trasformarla in un exploit affidabile.

Leggi anche: Bad Epoll trasforma una race condition use-after-free del kernel Linux in escalation a root

Gli stack identificano lo stesso accesso tra esecuzioni diverse

Il problema successivo consiste nel riconoscere lo stesso accesso durante esecuzioni differenti. Un indirizzo dati non è affidabile perché l’oggetto può essere allocato altrove; neppure l’indirizzo dell’istruzione basta quando funzioni comuni come memcpy() o spin_lock() vengono invocate molte volte. MAccConc utilizza quindi count-augmented stack traces, sequenze che descrivono non soltanto le funzioni attraversate ma anche quale chiamata specifica deve essere considerata all’interno di ciascun frame. Il punto di esecuzione diventa così indipendente dall’indirizzo concreto dell’oggetto e sufficientemente stabile da poter essere riconosciuto nei test successivi. Per supportare il meccanismo, KCOV deve conoscere ingresso e uscita dalle funzioni: Horn ha aggiunto la funzione richiesta a SanitizerCoverage e il relativo intervento è confluito in LLVM 23.1.0. L’idea permette di passare da “questa istruzione ha toccato un indirizzo” a una descrizione molto più precisa del percorso che ha condotto fino a quello specifico accesso.

KCOV_SET_DI forza l’ordine degli eventi concorrenti

Una volta identificati i punti interessanti, MAccConc può forzare l’ordine degli eventi tramite un nuovo ioctl chiamato KCOV_SET_DI. Il kernel può impostare un flag prima o dopo un accesso oppure sospendere un thread finché un determinato flag non viene attivato. Userspace può quindi costruire vincoli del tipo A-happens-before-B oppure definire passaggi più rigidi tra i contesti di esecuzione. L’automazione attuale comprende un tester per interleaving A-B-A: il thread A viene eseguito fino a un punto, il thread B completa il proprio lavoro e A riprende. La dimostrazione usa chiamate concorrenti a dup() e close() e riesce a produrre un risultato nel quale dup() restituisce lo stesso file descriptor appena chiuso, comportamento valido ma difficile da ottenere in modo affidabile lasciando semplicemente i thread correre. La tecnica richiama il valore delle race condition anche fuori da Linux: Project Zero aveva già sfruttato una condizione di gara nella ricerca sui bypass di Administrator Protection di Windows 11, dimostrando come il controllo preciso del timing possa diventare un passaggio determinante dentro una catena di privilege escalation.

GUI, terminale e test automatici compongono MAccConc

Il repository ufficiale MAccConc pubblicato da Project Zero comprende attualmente tre strumenti: una GUI per visualizzare trace KCOV e accessi memoria, una terminal UI più essenziale e kcov-autorace per esplorare automaticamente gli ordinamenti A-B-A. La GUI permette di filtrare i communication points, associare gli accessi al codice sorgente e creare vincoli tra eventi concorrenti. Read, write, free e interferenze possono essere visualizzati nello stesso flusso prima di chiedere al kernel di tentare uno specifico ordine di esecuzione. È un salto qualitativo rispetto alla rappresentazione manuale delle race condition attraverso diagrammi e call graph inseriti nei commit: lo sviluppatore non osserva soltanto che due thread si sovrappongono, ma può selezionare gli accessi che ritiene interessanti e provare deliberatamente a ricostruirne la sequenza. Il repository richiede una toolchain LLVM 23 o successiva, un kernel con le patch dedicate e configurazioni come CONFIG_KASAN_OUTLINE, CONFIG_KCOV_MEMORY e CONFIG_KCOV_EXT_RECORDS.

Il kernel upstream non integra ancora le patch

MAccConc resta però un prototipo da laboratorio. La modifica necessaria in LLVM è disponibile, mentre le patch richieste dal kernel non sono ancora confluite upstream e chi vuole sperimentare lo strumento deve utilizzare per ora il branch mantenuto da Horn. Il tool a riga di comando gestisce soltanto due thread concorrenti, mentre la GUI può rappresentare contesti aggiuntivi. Anche il percorso verso il fuzzing è incompleto: la parte kernel è stata progettata affinché possa diventare una sorgente di feedback per la ricerca automatica di race condition, ma manca ancora il tooling userspace necessario a trasformare questa architettura in un sistema di fuzzing general-purpose. Horn indica inoltre alcuni limiti pratici, compresa la perdita della traccia KCOV quando il kernel sotto test va in panic, proprio nel momento in cui il crash potrebbe contenere le informazioni più interessanti per il ricercatore.

Continua con:

• Project Zero ottiene root su Pixel 10 con una catena zero-click e un bug nel driver Tensor G5
• Linux 7.3-rc1 apre un nuovo ciclo del kernel tra maggiore complessità e nuovi sottosistemi

Dal regression test al fuzzing delle race condition

Le direzioni future indicate da Horn mostrano il potenziale più interessante del progetto. Project Zero valuta di sostituire parte dei vincoli “A prima di B” con ordinamenti completamente specificati e più deterministici, arricchire le trace con informazioni sui tipi degli oggetti attraverso debug info DWARF, integrare una semantica più alta per lock e unlock e riconoscere più rapidamente gli ordinamenti impossibili mediante strumenti di deadlock detection. Il passaggio successivo sarebbe usare i communication points come feedback per costruire test di fuzzing concorrente, avvicinando la ricerca automatica alle interazioni tra thread che i normali fuzzer faticano a esplorare. Il valore di MAccConc non consiste quindi in una nuova protezione distribuita agli utenti Linux, ma nel possibile miglioramento dell’ingegneria con cui vengono trovati e verificati i bug di concorrenza. In un kernel che continua ad aumentare dimensioni, parallelismo e complessità, come mostra il ciclo di sviluppo di Linux 7.3, la differenza tra “non riesco a riprodurlo” e “non esiste” resta enorme. Se le patch raggiungeranno upstream e il livello userspace maturerà, MAccConc potrà diventare una base per regression test ripetibili e fuzzing capace di esplorare ordinamenti che oggi dipendono ancora da tempismo, fortuna e modifiche manuali al codice.