Termini di Indicizzazione— kernel Linux, ricerca di vulnerabilità, segnale esterno, orchestrazione LLM, prioritizzazione euristica, syzbot, analisi di programmi, Codex.

I. Introduzione

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.

II. Segnale Esterno e Principi di Progettazione

A. Segnale Esterno Prima dell'Inferenza del Modello

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.

B. La Prioritizzazione Non È una Prova

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.

C. Raggiungibilità Prima della Classe di Bug

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.

D. Un Ramo di Indagine alla Volta

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.

E. Prove Piuttosto che Fiducia

Il prompt richiede che un finding forte descriva almeno i seguenti elementi.

1. entrypoint raggiungibile dall'attaccante,
2. campo controllato dall'attaccante o transizione di lifetime,
3. invariante di oggetto·lunghezza·stato che viene violata,
4. impatto concreto come corruzione, leak o escalation di privilegi,
5. motivo per cui i controlli esistenti non impediscono l'attacco.

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.

F. Lignaggio di Progettazione

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.

III. Architettura del Sistema

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

IV. Metodologia

A. Scoperta e Punteggio dei Candidati

Lo scanner itera i file .c e .h nelle directory di inclusione del profilo. Il punteggio di priorità del file f è concettualmente composto come segue.

Questo punteggio non è una misura di probabilità o sfruttabilità. Ogni elemento fornisce solo un ordine relativo per decidere quali file il modello deve esaminare per primo. L'implementazione attuale somma tutti i match a livello di riga e limita solo i segnali principali mostrati nel prompt. Il ricalcolo dello stesso risultato presuppone lo stesso albero dei sorgenti, profilo e JSON syzbot memorizzato nella cache. Il peso syzbot viene applicato a posteriori ai file già candidati tramite le euristiche di percorso e riga; un hit syzbot da solo non genera nuovi file candidati.

I principali segnali statici sono i seguenti.

• ioctl, handler compat, hook di operazioni sui file
• copy_from_user, copy_to_user, __user
• kmalloc, kzalloc, kvmalloc, allocazione di cache e percorsi di free
• operazioni refcount, atomic, kref
• calcoli di size·length e famiglie memcpy
• pattern relativi a lock, RCU e lifetime asincrono
• confini BPF, skb, XDP, netlink
• controlli di capability e namespace

B. Ambito Guidato dal Profilo

I profili integrati sono default, net, fs, io_uring, bpf e drivers. Il profilo definisce include path, pattern, pesi e il numero di segnali da conservare per file. Invece di applicare un'unica policy di punteggio all'intero kernel, riflette la superficie di attacco e le caratteristiche di lifetime specifiche di ciascun sottosistema.

C. Crash Intelligence

syzbot-fetch estrae titolo, sottosistema, tipo di bug e informazioni file:riga dalle pagine pubbliche dei bug syzbot del progetto syzkaller [2], creando una cache JSON. L'overlap esatto dei file è un External Signal forte; l'overlap del sottosistema è un External Signal debole. Poiché la dashboard live può cambiare, l'unità di riproduzione è il JSON salvato al momento del fetch. Le informazioni sui crash sono solo un punto di partenza per la caccia alle varianti e non vengono trattate come prova di nuove vulnerabilità.

D. Contratto di Sessione e Revisione

scan genera un manifest dei candidati classificati e i bundle di prompt principali. Ogni prompt include il percorso del target, il motivo del punteggio, i segnali di riga, il contesto syzbot e la procedura di audit.

La risposta del modello viene normalizzata in uno dei seguenti verdetti.

• cve_candidate
• plausible_security_bug
• latent_bug
• not_cve_candidate
• needs_more_context

La risposta include un Single best next target e un breve riepilogo. Le risposte obsolete senza target in sospeso vengono archiviate separatamente e non collegate a nuovi target.

V. Implementazione e Utilizzo

A. Requisiti

• Python 3.11 o superiore
• Codex CLI [3] e autenticazione per l'uso di autopilot
• Connessione di rete per la raccolta remota della dashboard syzbot

B. Installazione

I JSON dei profili integrati sono inclusi nella wheel. Le regole JSON esterne possono essere passate con --config /path/to/profile.json.

C. Workflow Minimo

--limit è il numero di candidati da mantenere nel manifest; --top è il numero di bundle di prompt da pre-generare inizialmente. I bundle per i rank successivi possono essere generati su richiesta.

D. Autopilot con Budget di Tempo

La sandbox predefinita è read-only. --sandbox workspace-write deve essere specificato solo se la modifica dei file è strettamente necessaria durante l'analisi.

E. Feed syzbot Opzionale

F. Artefatti di Sessione

VI. Risultato Operativo e Verifica

Questa versione non è rimasta una prova di concetto, ma è stata utilizzata in un'indagine reale su una vulnerabilità del kernel Linux.

TABELLA II — ESITO DELLA VULNERABILITÀ DIVULGATA

La verifica non è un benchmark di accuratezza del rilevamento, ma si concentra sulla regressione dell'implementazione e sulla distribuibilità.

TABELLA III — AMBITO DI VERIFICA INGEGNERISTICA

GitHub Actions esegue le regressioni unitarie, quindi installa la wheel in un nuovo ambiente e fa uno smoke-test della scansione con il profilo default. Il caso pubblico sopra è un risultato operativo ottenuto da un'indagine reale, ma non è un benchmark di precisione, recall o tasso di scoperta di CVE misurato su un corpus rappresentativo di alberi Linux.

VII. Considerazioni sulla Sicurezza

• Si raccomanda di mantenere la sandbox predefinita read-only.
• Non utilizzare --dangerously-bypass-approvals-and-sandbox in ambienti senza sandbox esterna.
• Commenti e identificatori di sorgenti non attendibili possono diventare input del modello; considerare l'iniezione di prompt.
• I finding generati dal modello devono essere ri-verificati da esseri umani per raggiungibilità e impatto prima della divulgazione o della segnalazione.
• I crash syzbot e i punteggi euristici elevati non devono essere citati come prova di vulnerabilità.

VIII. Limitazioni e Minacce alla Validità

1. Analisi lessicale. Non viene costruito un vero AST C, call graph o flusso di dati interprocedurale.
2. Bias del punteggio. Commenti, macro, token ripetuti e file di grandi dimensioni possono influenzare eccessivamente il punteggio.
3. Divario di raggiungibilità. Configurazione del kernel, privilegi, namespace e disponibilità del dispositivo non sono modellati automaticamente.
4. Fragilità dei dati esterni. L'integrazione syzbot è influenzata dai cambiamenti nella struttura HTML pubblica.
5. Dipendenza dal modello. La qualità dei risultati dipende dal modello utilizzato, dall'interpretazione del prompt e dal contesto del repository.
6. Ambito di valutazione. I test attuali verificano la regressione del software. Il caso CVE pubblico è un risultato di utilizzo reale, ma non sostituisce una valutazione statistica delle prestazioni di rilevamento della sicurezza.

IX. Retrospettiva

Dalla prima versione registrata nella cronologia Git, l'obiettivo è stato più vicino a "controllare quale codice guardare per primo e quali prove richiedere" che a "far trovare le vulnerabilità all'LLM da solo". L'indagine assistita da v1 che ha scoperto CVE-2026-31720 ha fornito un caso di applicazione reale di unità di indagine ristrette e contratto di prove. La v2 estende questo workflow al triage consapevole della provenienza, preservando insieme lo stato del repository e i riferimenti noti. Se lo reimplementassi oggi, darei priorità a quanto segue.

1. symbol/call graph basato su tree-sitter o Clang,
2. normalizzazione del punteggio che considera dimensione del file e hit ripetuti,
3. rimozione della duplicazione CLI/autopilot tramite la separazione dei livelli review e runner,
4. manifest versionato e scrittura atomica dello stato,
5. risposte del modello basate su JSON Schema ed evidenze strutturate,
6. collegamento automatico di crash syzbot, commit di fix e varianti vicine.

Tuttavia, il principio centrale che vorrei mantenere è External Signal. Non lasciare che l'LLM esplori vagamente l'intero codebase; ripetere unità di indagine ristrette da segnali esterni al modello, incentrate su raggiungibilità e invarianti.

X. Conclusione

Kernel Codex Harness non sostituisce il rilevamento di vulnerabilità del kernel Linux. Invece, trasforma External Signal in una classificazione spiegabile e limita la revisione LLM a un processo di indagine breve e con stato. Questa struttura è stata utilizzata in un'indagine reale per la scoperta di CVE-2026-31720. Il risultato fondamentale del progetto non è rivendicare un nuovo algoritmo di analisi, ma definire la revisione di sicurezza LLM come allocazione dell'attenzione tramite segnale esterno, contratto di prove e orchestrazione riproducibile e applicarla a un workflow di ricerca reale.

Appendice A. Struttura del Repository

Le procedure operative dettagliate sono disponibili in docs/.

Riferimenti

[1] Protect AI, "vulnhuntr," repository GitHub. https://github.com/protectai/vulnhuntr

[2] Google, "syzkaller and syzbot," repository GitHub. https://github.com/google/syzkaller

[3] OpenAI, "Codex CLI." https://developers.openai.com/codex/cli/

Licenza

Concesso in licenza sotto la Apache License 2.0.