foxirain/linux-kernel-codex-harness-v2Harness di ricerca sulle vulnerabilità del kernel Linux basato sulla provenienza, utilizzato nell'indagine su CVE-2026-53075
Strumento di Ricerca · Importazione Originale: 3 Aprile 2026 · Revisione Documentazione v2: 11 Luglio 2026
Segnale Esterno: Dall'Allocazione dell'Attenzione al Triage Basato sulla Provenienza
Usa osservazioni riproducibili per guidare l'attenzione del modello, poi usa la provenienza del repository per organizzare le code di revisione—mai per rivendicare una prova.
Lineaggio del Progetto— Kernel Codex Harness v1 · Allocazione dell'Attenzione → Kernel Codex Harness v2 · Triage Basato sulla Provenienza
Stato del progetto. Questo repository è un harness di ricerca assistito da LLM che fa evolvere il workflow di attention-allocation della v1 fino al triage basato sulla provenienza per l'analisi reale delle vulnerabilità del kernel Linux. Questa versione è stata utilizzata per scoprire la vulnerabilità pubblicata come CVE-2026-53075. Non è un rilevatore automatico di vulnerabilità, un giudice di novità, un validatore di exploit o uno strumento di garanzia della sicurezza del kernel; la validazione finale e la segnalazione sono eseguite da esseri umani.
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.
La revisione della sicurezza del kernel comporta due diversi tipi di incertezza.
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à.
Il Segnale Esterno pre-inferenza non è un giudizio dell'LLM ma un'osservazione calcolata prima dell'esecuzione del modello.
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.
La fase post-inferenza combina un verdetto forte del modello con le seguenti informazioni.
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.
I finding forti sono organizzati operativamente in uno dei seguenti bucket di revisione.
| Bucket | Significato |
|---|---|
new_candidate | Candidato con provenienza verificata e nessun segnale bloccante di dirty/known rilevato |
known_issue | Candidato con riferimento noto non negato o con commit indicato dalla risposta come fix/relazione upstream e confermato come ancestore del HEAD corrente |
dirty_tree_suspect | Candidato in cui non si può escludere l'influenza di un repository dirty o di un target dirty |
provenance_unknown | Candidato per cui non è stato possibile verificare in modo affidabile repository Git, status o HEAD |
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à.
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.
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.
Un finding forte deve spiegare almeno quanto segue.
Il parser normalizza solo verdetto e prossimo target; non dimostra automaticamente la completezza di queste evidenze.
