foxirain/linux-kernel-codex-harness-v2Harness de recherche de vulnérabilités du noyau Linux sensible à la provenance, utilisé dans l'investigation de la CVE-2026-53075
Outil de recherche · Import d'origine : 3 avril 2026 · Révision de la documentation v2 : 11 juillet 2026
Signal externe : de l'allocation de l'attention au triage sensible à la provenance
Utilisez des observations reproductibles pour guider l'attention du modèle, puis utilisez la provenance du dépôt pour organiser les files de revue — jamais pour prétendre à une preuve.
Lignée du projet — Kernel Codex Harness v1 · Allocation de l'attention → Kernel Codex Harness v2 · Triage sensible à la provenance
Statut du projet. Ce dépôt est un harnais de recherche assisté par LLM qui fait évoluer le workflow d'allocation de l'attention de v1 vers un triage sensible à la provenance pour la recherche réelle de vulnérabilités dans le noyau Linux. Cette version a été utilisée pour découvrir la vulnérabilité publiée sous le nom CVE-2026-53075. Il ne s'agit pas d'un détecteur automatique de vulnérabilités, d'un juge de nouveauté, d'un validateur d'exploit ni d'un outil d'assurance de sécurité du noyau ; la validation finale et le rapport sont effectués par des humains.
Abstract— Faire explorer directement une base de code aussi vaste que le noyau Linux à un LLM disperse le contexte et confond facilement la présence d'API dangereuses avec une exploitabilité réelle. Kernel Codex Harness v2 définit ce problème en deux étapes de traitement du signal externe. Avant l'appel au modèle, les poids de chemin, les correspondances lexicales et le chevauchement syzbot mis en cache classent les fichiers candidats pour répartir l'attention. Après la réponse du modèle, la branche Git, le HEAD, l'état dirty et les marqueurs CVE, commit et known extraits de la réponse sont combinés pour classer les findings forts dans des buckets de revue sensibles à la provenance. Ce harnais a été utilisé dans une recherche réelle sur le noyau Linux pour découvrir un défaut de vérification des permissions du network namespace cible de PPP, publié sous le nom CVE-2026-53075. Le triage est une heuristique qui organise la file d'investigation ; en particulier, new_candidate signifie seulement qu'aucun indice connu ni problème de provenance n'a été trouvé, et non une preuve de nouveauté. Tous les findings exigent une revalidation humaine de l'atteignabilité depuis l'espace utilisateur, de la rupture d'invariant et de l'impact concret.
Index Terms— noyau Linux, recherche de vulnérabilités, signal externe, provenance, triage heuristique, orchestration LLM, syzbot, Codex.
La revue de sécurité du noyau comporte deux types d'incertitude distincts.
Le problème central de v1 était le premier, à savoir l'allocation de l'attention. v2 conserve ce principe tout en étendant le second problème au triage sensible à la provenance. Les deux versions ont chacune été utilisées dans des recherches réelles : l'investigation assistée par v1 a conduit à CVE-2026-31720, et l'investigation assistée par v2 a conduit à CVE-2026-53075.
Les observations hors modèle réduisent le périmètre d'investigation, et après la réponse du modèle, une provenance de dépôt vérifiable est attachée. Aucun signal, à aucune étape, ne prouve une vulnérabilité ou une nouveauté.
Le signal externe pré-inférence n'est pas un jugement du LLM mais une observation calculée avant l'exécution du modèle.
Avec la même arborescence source, le même profil et le même JSON syzbot mis en cache, le classement des candidats peut être recalculé. Ce score n'est ni une probabilité ni une exploitabilité, mais un ordre relatif pour décider où regarder en premier.
L'étape post-inférence combine un verdict fort du modèle avec les informations suivantes.
Dans ce document, le signal externe post-inférence désigne uniquement la provenance collectée indépendamment du modèle, comme le dépôt/statut Git, la branche, le HEAD, l'état dirty et l'ascendance des commits locaux. Les marqueurs CVE, commit et known sont des références dérivées du modèle extraites de la réponse du modèle, et non un signal externe ni un fait faisant autorité. Le triage combine les deux types d'entrées mais enregistre leur source séparément.
Un finding fort est opérationnellement classé dans l'un des buckets de revue suivants.
| Bucket | Signification |
|---|---|
new_candidate | Candidat dont la provenance est confirmée et pour lequel aucun signal bloquant dirty/known n'a été détecté |
known_issue | Candidat avec une référence connue non niée, ou un commit que la réponse désigne comme correctif/relation upstream et qui est inclus dans le HEAD actuel |
dirty_tree_suspect | Candidat dont l'influence d'un dépôt dirty ou d'une cible dirty ne peut être exclue |
provenance_unknown | Candidat dont le dépôt Git, le statut ou le HEAD n'a pas pu être confirmé de manière fiable |
Pour tous les résultats de classification, novelty_proven est false. new_candidate ne signifie pas « nouvelle vulnérabilité » mais une file prioritaire pour qu'un humain poursuive l'investigation de nouveauté.
L'audit vérifie d'abord les frontières initiées depuis l'espace utilisateur, comme syscall, ioctl, netlink, procfs, les systèmes de fichiers, BPF et les hooks de pilotes. Ce n'est qu'ensuite que les classes de bugs telles que UAF, OOB, refcount, race, fuite d'informations et vérification de capacités sont évaluées.
Une unité d'investigation est limitée à un fichier et à ses chemins proches d'appelants, de teardown et de libération. Les suivis manuels proposés par le modèle sont limités à deux au maximum afin de maintenir des chemins courts et vérifiables plutôt qu'une exploration large.
Un finding fort doit au minimum expliquer ce qui suit.
Le parseur normalise le verdict et la cible suivante, mais ne prouve pas automatiquement la complétude de ces preuves.
