Abstract— Lasciare che un LLM esplori direttamente un codebase grande come il kernel Linux disperde il contesto e confonde facilmente l'esistenza di API pericolose con l'effettiva sfruttabilità. Kernel Codex Harness v2 definisce questo problema come gestione di Segnale Esterno in due fasi. Prima della chiamata al modello, i pesi dei percorsi, i hit lessicali e la sovrapposizione con syzbot memorizzata nella cache classificano i file candidati per allocare l'attenzione. Dopo la risposta del modello, branch Git, HEAD e dirty state vengono combinati con CVE, commit e marker noti estratti dalla risposta per classificare i finding forti in bucket di revisione basati sulla provenienza. Questo harness è stato utilizzato in un'analisi reale del kernel Linux per scoprire un difetto nella verifica dei permessi del network namespace di destinazione di PPP, pubblicato come CVE-2026-53075. Il triage è un'euristica per organizzare la coda di analisi; in particolare, new_candidate significa solo che non sono stati trovati indizi noti o problemi di provenienza, non è una prova di novità. Tutti i finding richiedono una ri-validazione umana di raggiungibilità da userspace, rottura degli invariant e impatto concreto.

Termini di Indicizzazione— kernel Linux, ricerca di vulnerabilità, segnale esterno, provenienza, triage euristico, orchestrazione LLM, syzbot, Codex.

I. Introduzione

La revisione della sicurezza del kernel comporta due diversi tipi di incertezza.

1. Dove guardare per primo. L'intero albero dei sorgenti è troppo grande per essere gestito in un unico contesto del modello.
2. Come trattare i finding forti prodotti dal modello. Modifiche locali, fix esistenti, CVE noti o uno stato del repository incompleto possono contaminare le conclusioni.

Il problema centrale della v1 era il primo, cioè l'allocazione dell'attenzione. La v2 mantiene quel principio ed estende il secondo problema con il triage basato sulla provenienza. Entrambe le versioni sono state utilizzate in analisi reali: l'analisi assistita da v1 ha portato a CVE-2026-31720, quella assistita da v2 a CVE-2026-53075.

Le osservazioni esterne al modello restringono l'ambito dell'analisi e, dopo la risposta del modello, viene allegata una provenienza del repository verificabile. Nessun segnale in nessuna fase dimostra una vulnerabilità o una novità.

II. Segnale Esterno e Principi di Progettazione

A. Fase 1 — Allocazione dell'Attenzione Prima dell'Inferenza

Il Segnale Esterno pre-inferenza non è un giudizio dell'LLM ma un'osservazione calcolata prima dell'esecuzione del modello.

• Pesi dei percorsi del kernel e dei sottosistemi
• Hit lessicali come usercopy, allocator, refcount, size, lock
• Sovrapposizione file/sottosistema con JSON syzbot memorizzato

Usando lo stesso albero dei sorgenti, profilo e JSON syzbot memorizzato nella cache, il ranking dei candidati può essere ricalcolato. Questo punteggio non è una probabilità o sfruttabilità ma un ordine relativo per decidere dove guardare per primo.

B. Fase 2 — Triage Basato sulla Provenienza Dopo l'Inferenza

La fase post-inferenza combina un verdetto forte del modello con le seguenti informazioni.

• Presenza di un repository Git e successo della raccolta dello status
• Branch e HEAD
• Dirty state del repository e del file target
• CVE, hash di commit e marker di problemi noti estratti dalla risposta
• Espressioni di negazione o riferimenti non correlati presenti nella risposta

In questo documento, il Segnale Esterno post-inferenza si riferisce solo alla provenienza raccolta indipendentemente dal modello, come repository/status Git, branch, HEAD, dirty state e ancestry dei commit locali. CVE, commit e marker noti sono riferimenti derivati dal modello estratti dalla risposta del modello, non Segnale Esterno né fatti autorevoli. Il triage combina i due tipi di input ma registra separatamente la loro origine.

C. Bucket Euristici, Non Prove di Novità

I finding forti sono organizzati operativamente in uno dei seguenti bucket di revisione.

novelty_proven è false per tutti i risultati di classificazione. new_candidate non significa "nuova vulnerabilità" ma una coda da dare priorità agli esseri umani per continuare l'indagine di novità.

D. Raggiungibilità Prima della Classe di Bug

L'audit verifica prima i confini raggiungibili da userspace come syscall, ioctl, netlink, procfs, filesystem, BPF e hook di driver. Solo dopo valuta classi di bug come UAF, OOB, refcount, race, info leak e controlli di capability.

E. Un Ramo di Indagine alla Volta

Un'unità di indagine è limitata a un singolo file e ai suoi percorsi vicini di caller, teardown e free. I follow-up manuali proposti dal modello sono limitati a un massimo di due per mantenere percorsi brevi e verificabili piuttosto che un'esplorazione ampia.

F. Evidenza Piuttosto che Fiducia

Un finding forte deve spiegare almeno quanto segue.

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

Il parser normalizza solo verdetto e prossimo target; non dimostra automaticamente la completezza di queste evidenze.

G. Lineaggio di Progettazione

Il flusso iniziale trae origine dall'idea di analisi per file, estensione limitata del contesto e output strutturato usata da vulnhuntr di Protect AI [1]. In questo progetto è stato riprogettato per la superficie del kernel raggiungibile da userspace, il lifetime degli oggetti del kernel, i percorsi di teardown e la sovrapposizione con syzbot. Il contributo aggiuntivo della v2 è l'inserimento di una fase di triage dei finding basata sulla provenienza del repository dopo l'allocazione dell'attenzione.

III. Architettura del Sistema

Fig. 1. Il Segnale Esterno pre-inferenza classifica unità di revisione riproducibili. Il triage post-inferenza combina la provenienza Git indipendente dal modello con i riferimenti della risposta derivati dal modello, senza trattare questi ultimi come Segnale Esterno o fatto autorevole. La validazione umana rimane esterna a entrambe le fasi automatizzate.

TABELLA I — RESPONSABILITÀ DEI MODULI PRINCIPALI

IV. Metodologia

A. Scoperta e Punteggio dei Candidati

Lo scanner itera i file .c e .h nelle directory incluse dal profilo.

L'implementazione attuale somma i match a livello di riga e limita solo il numero di segnali principali mostrati nel prompt. Il punteggio determina l'ordine di indagine del modello ma non è un valore statistico calibrato sulla probabilità di vulnerabilità.

I principali segnali statici sono i seguenti.

• ioctl, handler compat, hook di operazioni su file
• copy_from/to_user e __user
• kmalloc/kzalloc/kvmalloc, allocazione cache e percorsi di free
• refcount, atomic, kref
• calcoli di size·length e famiglia memcpy
• lock, RCU, lifetime asincrono
• BPF, skb, XDP, netlink
• controlli di capability e namespace

B. Ambito Guidato dal Profilo

C. Intelligenza dai Crash

syzbot-fetch estrae titolo, sottosistema, tipo di bug e file:linea dalle pagine pubbliche dei bug di syzbot e li salva in JSON. La sovrapposizione esatta di file è un segnale di ranking forte, la sovrapposizione di sottosistema è un segnale debole. La dashboard live può cambiare, quindi l'unità riproducibile è il JSON salvato al momento del fetch. La sovrapposizione di crash è un suggerimento per la caccia alle varianti, non una prova di vulnerabilità.

D. Contratto di Sessione e Revisione

scan genera un manifest completo di candidati classificati e i bundle di prompt principali. --limit è il numero di candidati da mantenere nel manifest e --top è il numero di bundle da generare in anticipo. I rank successivi possono essere generati su richiesta.

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 revisione manuale e l'autopilot usano lo stesso review_state.json, lo stesso percorso fisso delle risposte e lo stesso parser di verdetto.

E. Raccolta della Provenienza e Triage

doctor e l'autopilot verificano la presenza di un repository Git, il successo della raccolta dello status, branch, HEAD e percorsi dirty. Uno stato in cui la provenienza non può essere determinata non viene considerato pulito ma preservato come provenance_unknown.

Il triage dei verdetti forti segue approssimativamente questa priorità.

1. se la provenienza non è affidabile → provenance_unknown,
2. se il repository o il target è dirty → dirty_tree_suspect,
3. se esiste un CVE correlato o un marker non negato, o se il commit indicato dalla risposta come fix/relazione upstream è un ancestore del HEAD corrente → known_issue,
4. altrimenti → new_candidate.

Espressioni di negazione o non correlazione come "not a known issue", "unrelated to CVE-…" non vengono usate come base per known. Nel verdetto finale vengono registrati insieme il verdetto originale, branch, HEAD, status, dirty state, riferimento corrispondente e motivo.

L'attuale classificazione in bucket basata sulla provenienza e il writer JSONL si applicano al percorso di ingest dell'autopilot. loop e ingest manuali usano lo stesso stato di sessione di base e lo stesso parser di verdetto ma non generano artefatti di bucket.

V. Implementazione e Utilizzo

A. Requisiti

• Python 3.11 o superiore
• Albero dei sorgenti del kernel Linux
• Git per l'uso di provenance/doctor/autopilot
• CLI Codex e autenticazione per l'uso di autopilot [3]
• Connessione di rete per la raccolta remota di syzbot

Le dipendenze runtime di Python sono solo la libreria standard.

B. Installazione

I profili JSON integrati sono inclusi nella wheel. Regole personalizzate possono essere passate con --config /path/to/profile.json.

C. Workflow Minimo

Le risposte manuali di Codex vengono salvate in codex_response.txt come indicato dal runbook e poi possono essere ingerite con il comando seguente.

D. Autopilot con Budget di Tempo

La sandbox predefinita di Codex è read-only. --require-clean-tree consente l'esecuzione solo quando repository Git, status e HEAD sono verificati e l'albero di lavoro è pulito. --stop-on-finding si ferma solo quando il risultato del triage euristico è new_candidate.

E. Feed syzbot Opzionale

F. Artefatti di Sessione

AUTOPILOT_FINDINGS.jsonl preserva verdetto, bucket, motivo, branch, HEAD, stato della provenienza, riferimento corrispondente e percorsi di finding/archivio in una forma elaborabile.

VI. Risultato Operativo e Verifica

La v2 ha applicato la struttura estesa a un'analisi reale delle vulnerabilità del kernel Linux.

TABELLA II — RISULTATO DI VULNERABILITÀ DIVULGATA

I 16 test di regressione non sono un benchmark di accuratezza del rilevamento di sicurezza ma si concentrano sul contratto software e sulla distribuibilità.

• Regressione delle risorse di allocator e profili integrati
• Verifica che i verdetti negativi e le espressioni CVE in prosa generale non vengano ribaltati in finding forti
• Limite dei follow-up manuali e ordinamento dei rank
• Archiviazione di risposte stale senza target in sospeso
• Sandbox read-only predefinita e argomento CLI positivo
• Provenienza fail-closed per repository mancante/non-Git/errore di status
• Triage di target dirty, riferimento noto, negazione e CVE non correlato
• Preservazione della cronologia di sessione e JSONL dei metadati di classificazione
• Contratto degli artefatti di parse-error e finding
• Smoke test di scansione del profilo dalla wheel installata

GitHub Actions esegue i test di regressione su Python 3.11 e 3.12, installa la wheel e fa uno smoke-test dei 6 profili impacchettati e della scansione predefinita. Il caso divulgato sopra è un risultato operativo ottenuto da un'indagine reale, ma non è un benchmark di precision, recall, sfruttabilità o tasso di scoperta CVE misurato su un corpus rappresentativo di alberi Linux.

VII. Considerazioni sulla Sicurezza

• La sandbox predefinita di Codex è read-only e si raccomanda di mantenerla.
• Se la provenienza pulita è importante, usare doctor seguito da --require-clean-tree.
• Non interpretare come pulito uno stato non-Git o con verifica di status/HEAD fallita.
• --dangerously-bypass-approvals-and-sandbox non va usato al di fuori di ambienti sperimentali isolati.
• Anche commenti e identificatori dei sorgenti sono input del modello, quindi considerare la possibilità di prompt injection.
• Le stringhe CVE e commit sono solo riferimenti della risposta, non conferme autorevoli.
• Prima di divulgare o segnalare un finding, un essere umano deve ri-verificare raggiungibilità, invariant, impatto e versioni interessate.

VIII. Limitazioni e Minacce alla Validità

1. Analisi lessicale. Non costruisce un vero AST C, call graph o data flow interprocedurale.
2. Bias del punteggio. Commenti, macro, token ripetuti e file grandi possono influenzare eccessivamente il punteggio.
3. Gap di raggiungibilità. Non modella automaticamente kernel config, privilegi, namespace e disponibilità dei dispositivi.
4. Fragilità dei dati esterni. L'integrazione syzbot è influenzata dai cambiamenti nella struttura dell'HTML pubblico.
5. Solo provenienza locale. L'ancestry Git è relativa al HEAD del checkout corrente e non rappresenta tutta la storia upstream e dei vendor.
6. Riferimenti derivati dalla risposta. CVE e marker noti sono estratti dalla risposta del modello, quindi sono possibili omissioni, allucinazioni o fraintendimenti contestuali.
7. Triage euristico. Sia new_candidate che known_issue non sono giudizi finali di novità.
8. Dipendenza dal modello. La qualità dei risultati dipende dal modello, dall'interpretazione del prompt e dal contesto del repository disponibile.
9. Ambito di valutazione. I test attuali verificano la regressione software. Il caso CVE divulgato è un risultato d'uso reale ma non sostituisce una valutazione statistica delle prestazioni di rilevamento della sicurezza.

IX. Evoluzione e Retrospettiva

La v1 (repository) si concentrava sul problema di allocare l'attenzione dell'LLM con Segnale Esterno ed è stata usata in un'indagine reale assistita da v1 che ha portato alla scoperta di CVE-2026-31720. La v2 prosegue la stessa filosofia di ricerca estendendola per registrare anche lo stato del repository e i riferimenti derivati dalla risposta dopo che il modello produce un finding forte. In un'indagine successiva che ha usato questa struttura è stato scoperto CVE-2026-53075.

Due principi devono essere mantenuti in questa evoluzione.

1. Non fraintendere il punteggio pre-inferenza come prova di vulnerabilità.
2. Non fraintendere il bucket post-inferenza come prova di novità.

Se si dovesse estendere di nuovo, si darebbe priorità a call graph Clang/tree-sitter, normalizzazione dei punteggi, manifest versionati con locking dello stato tra processi, adapter per database CVE/fix autorevoli e separazione di runner, triage e writer degli artefatti. La scrittura dello stato attuale usa file temporanei e sostituzione atomica.

X. Conclusione

Kernel Codex Harness v2 non sostituisce il rilevamento delle vulnerabilità. Prima della chiamata al modello, il Segnale Esterno distribuisce il budget di indagine su candidati spiegabili; dopo la chiamata al modello, il segnale di provenienza organizza i finding forti in code revisionabili. Questa struttura è stata usata in un'indagine reale per la scoperta di CVE-2026-53075, e il risultato principale del progetto non è un algoritmo che determina automaticamente la novità, ma un workflow pratico di revisione della sicurezza con LLM che separa esplicitamente l'allocazione dell'attenzione dal triage basato sulla provenienza.

Appendice A. Struttura del Repository

Le operazioni manuali dettagliate sono disponibili nella guida CLI Codex, l'esecuzione automatica e il triage nella guida Autopilot e l'intelligenza dai crash nella guida syzbot.

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.