foxirain/linux-kernel-codex-harnessHarness di ricerca sulle vulnerabilità del kernel Linux basato su prove concrete, utilizzato nell'indagine sulla CVE-2026-31720
Strumento di Ricerca · Importazione Originale: 3 Aprile 2026 · Revisione Documentazione: 11 Luglio 2026
Filosofia Fondamentale — Segnale Esterno
Lascia che osservazioni riproducibili al di fuori dell'inferenza del modello guidino l'attenzione; non scambiare mai la priorità per una prova.
Stato del progetto. Questo repository è una versione iniziale di un harness di ricerca assistito da LLM costruito e utilizzato per l'indagine di vulnerabilità reali del kernel Linux. Questa versione è stata utilizzata per scoprire la vulnerabilità pubblicata come CVE-2026-31720. L'harness dà priorità ai bersagli di indagine ma non dimostra automaticamente le vulnerabilità né garantisce la sicurezza del kernel; la verifica finale e la segnalazione sono svolte da esseri umani.
Abstract— Lasciare che un LLM esplori direttamente un codebase delle dimensioni del kernel Linux disperde rapidamente il contesto e confonde facilmente l'esistenza di API pericolose con la reale sfruttabilità. Kernel Codex Harness definisce questo problema non come rilevamento automatico di vulnerabilità, ma come prioritizzazione dell'indagine e orchestrazione basata sullo stato. Questo progetto chiama External Signal il principio di controllare l'attenzione del modello con osservazioni riproducibili calcolate al di fuori del ragionamento LLM. Combina percorsi del kernel, confini userspace, segnali statici relativi a lifetime·usercopy·refcount·size e intelligence opzionale sui crash di syzbot per classificare i file candidati, trasformando ciascun candidato in un bundle di prompt ristretto. La revisione manuale e l'autopilot basato su budget di tempo utilizzano lo stesso contratto di risposta e lo stesso stato di sessione. Questo harness è stato utilizzato in un'indagine reale sul kernel Linux per scoprire una scrittura out-of-bounds nello stack nel percorso audio del gadget USB; il difetto è stato pubblicato come CVE-2026-31720. Questa implementazione non è un analizzatore statico di precisione, ma un workflow di ricerca che limita l'ambito dell'indagine LLM con euristiche spiegabili; ogni finding richiede una ri-verifica umana di raggiungibilità, violazione di invarianti e impatto concreto.
Termini di Indicizzazione— kernel Linux, ricerca di vulnerabilità, segnale esterno, orchestrazione LLM, prioritizzazione euristica, syzbot, analisi di programmi, Codex.
La revisione di sicurezza del kernel Linux presenta due tipi di problemi di scala. In primo luogo, l'intero albero dei sorgenti è troppo grande per essere gestito in un unico contesto LLM. In secondo luogo, segnali come copy_from_user, allocator, refcount e lock sono comuni ma non implicano di per sé una vulnerabilità. L'analista deve prima decidere "dove guardare" e poi dimostrare separatamente la raggiungibilità da userspace e le transizioni di stato concrete.
La filosofia fondamentale di questo progetto è External Signal.
Non lasciamo che l'LLM decida da solo dove guardare. Segnali riproducibili al di fuori del ragionamento del modello allocano l'attenzione, ma le conclusioni sulle vulnerabilità sono determinate solo da prove di raggiungibilità e invarianti.
Pertanto, l'harness non fa esplorare vagamente l'intero kernel al modello. Prioritizza i file, fornisce un solo ramo di indagine alla volta e richiede prima la struttura delle prove, non le conclusioni.
External Signal non è un giudizio generato dall'LLM, ma un'osservazione determinata prima dell'esecuzione del modello e ricalcolabile dallo stesso albero dei sorgenti, profilo e JSON syzbot salvato. Pesi dei percorsi, hit di espressioni regolari e overlap syzbot memorizzato nella cache rientrano in questa categoria. Questo segnale viene utilizzato solo per la classificazione dei candidati e il contesto dei prompt; non viene promosso a verdetto o prova.
In questo documento, External Signal si riferisce all'intera filosofia del progetto. Il modello dati ExternalSignal nel codice rappresenta attualmente solo i segnali derivati da syzbot, quindi l'ambito dei due termini è diverso.
Gli hit di espressioni regolari, i percorsi ad alto rischio e l'overlap syzbot sono tutti segnali per l'ordine di indagine. Un punteggio elevato non costituisce un finding di sicurezza se il percorso di chiamata effettivo, i privilegi, la configurazione del kernel, il namespace o la disponibilità del dispositivo non consentono l'accesso all'attaccante.
L'audit verifica prima i confini che iniziano da userspace, come syscall, ioctl, netlink, procfs, filesystem, BPF e hook di driver. Solo successivamente valuta classi di bug come UAF, OOB, refcount, race, info leak e controlli di capability.
Un'unità di indagine è limitata per impostazione predefinita a un singolo file e ai suoi caller, teardown e percorsi di free vicini. I follow-up manuali raccomandati dal modello sono consentiti al massimo due volte. Questa limitazione non mira a ridurre la capacità di esplorazione, ma a mantenere le conclusioni entro un ambito verificabile.
Il prompt richiede che un finding forte descriva almeno i seguenti elementi.
Se le prove sono insufficienti, il modello restituisce un singolo target successivo da verificare invece di affermare con forza una vulnerabilità. Questo è un contratto di prove a livello di prompt; l'attuale parser non verifica automaticamente la completezza di ciascuna prova. Poiché l'ingestion normalizza verdetto e target successivo, la verifica finale delle prove è responsabilità umana.
Il flusso di indagine iniziale trae origine dalle idee di analisi per file, espansione limitata del contesto e output strutturato utilizzate da vulnhuntr di Protect AI [1]. In questo progetto non è stato applicato direttamente all'analisi di applicazioni Python, ma è stato riprogettato attorno alla superficie del kernel raggiungibile da userspace, al lifetime degli oggetti del kernel, ai percorsi di teardown e all'overlap syzbot. In particolare, separare i segnali di priorità dalla prova della vulnerabilità e verificare la raggiungibilità prima della classe di bug è la scelta progettuale centrale dell'harness per il kernel.
Fig. 1. Il livello External Signal trasforma le osservazioni calcolate prima dell'inferenza del modello in unità di revisione classificate. Alloca l'attenzione ma non stabilisce la prova della vulnerabilità.
TABELLA I — RESPONSABILITÀ DEI MODULI PRINCIPALI
