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.

I. Introduction

La revue de sécurité du noyau comporte deux types d'incertitude distincts.

1. Où regarder en premier. L'arborescence source complète est trop vaste pour tenir dans un seul contexte de modèle.
2. Comment traiter un finding fort émis par le modèle. Les modifications locales, les correctifs existants, les CVE connues ou un état de dépôt incomplet peuvent contaminer les conclusions.

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é.

II. Signal externe et principes de conception

A. Étape 1 — Allocation de l'attention avant l'inférence

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.

• Poids des chemins et des sous-systèmes du noyau
• Correspondances lexicales : usercopy, allocator, refcount, size, lock, etc.
• Chevauchement file/sous-système avec le JSON syzbot mis en cache

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.

B. Étape 2 — Triage sensible à la provenance après l'inférence

L'étape post-inférence combine un verdict fort du modèle avec les informations suivantes.

• Présence d'un dépôt Git et succès de la collecte du statut
• Branche et HEAD
• État dirty du dépôt et du fichier cible
• CVE, hash de commit et marqueur de problème connu extraits de la réponse
• Expressions de négation ou de référence non liée apparaissant dans la réponse

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.

C. Buckets heuristiques, pas une preuve de nouveauté

Un finding fort est opérationnellement classé dans l'un des buckets de revue suivants.

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é.

D. Atteignabilité avant la classe de bug

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.

E. Une branche d'investigation à la fois

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.

F. Preuves plutôt que confiance

Un finding fort doit au minimum expliquer ce qui suit.

1. un point d'entrée atteignable par l'attaquant,
2. un champ contrôlé par l'attaquant ou une transition de durée de vie,
3. un invariant d'objet, de longueur ou d'état qui se brise,
4. un impact concret : corruption, fuite, élévation de privilèges, etc.,
5. la raison pour laquelle les vérifications existantes n'empêchent pas l'attaque.

Le parseur normalise le verdict et la cible suivante, mais ne prouve pas automatiquement la complétude de ces preuves.

G. Lignée de conception

Le flux initial s'inspire de l'analyse par fichier, de l'extension limitée du contexte et des résultats structurés utilisés par vulnhuntr de Protect AI [1]. Dans ce projet, cela a été redessiné pour la surface du noyau atteignable depuis l'espace utilisateur, la durée de vie des objets du noyau, les chemins de teardown et le chevauchement syzbot. La contribution supplémentaire de v2 est l'ajout d'une étape de triage des findings utilisant la provenance du dépôt après l'allocation de l'attention.

III. Architecture du système

Fig. 1. Le signal externe pré-inférence classe des unités de revue reproductibles. Le triage post-inférence combine la provenance Git indépendante du modèle avec les références de réponse dérivées du modèle, sans traiter ces dernières comme un signal externe ni un fait faisant autorité. La validation humaine reste en dehors des deux étapes automatisées.

TABLEAU I — RESPONSABILITÉS DES MODULES PRINCIPAUX

IV. Méthodologie

A. Découverte et score des candidats

Le scanner parcourt les fichiers .c et .h sous le répertoire include du profil.

L'implémentation actuelle additionne les correspondances au niveau des lignes et limite uniquement le nombre de signaux principaux affichés dans le prompt. Le score détermine l'ordre d'investigation du modèle mais n'est pas une valeur statistique calibrée pour la probabilité de vulnérabilité.

Les principaux signaux statiques sont les suivants.

• ioctl, gestionnaire compat, hook d'opérations de fichier
• copy_from/to_user et __user
• kmalloc/kzalloc/kvmalloc, allocation de cache et chemins de libération
• refcount, atomic, kref
• calculs de size/length et familles memcpy
• lock, RCU, durée de vie asynchrone
• BPF, skb, XDP, netlink
• vérifications de capacités et de namespaces

B. Périmètre piloté par profil

C. Intelligence sur les crashes

syzbot-fetch extrait le titre, le sous-système, le type de bug et le fichier:ligne des pages de bugs publiques syzbot et les enregistre en JSON. Un chevauchement exact de fichier est un signal de classement fort ; un chevauchement de sous-système est un signal faible. Le tableau de bord en direct pouvant changer, l'unité de reproduction est le JSON enregistré au moment de la collecte. Le chevauchement de crash est un indice pour la chasse aux variantes, pas une preuve de vulnérabilité.

D. Contrat de session et de revue

scan génère le manifeste complet des candidats classés et les bundles de prompts principaux. --limit est le nombre de candidats conservés dans le manifeste et --top est le nombre de bundles pré-générés. Les rangs suivants peuvent également être générés à la demande.

La réponse du modèle est normalisée en l'un des verdicts suivants.

• cve_candidate
• plausible_security_bug
• latent_bug
• not_cve_candidate
• needs_more_context

La revue manuelle et l'autopilot utilisent le même review_state.json, le même chemin de réponse fixe et le même parseur de verdict.

E. Collecte de la provenance et triage

doctor et l'autopilot vérifient la présence d'un dépôt Git, le succès de la collecte du statut, la branche, le HEAD et les chemins dirty. Un état dont la provenance ne peut pas être établie n'est pas considéré comme clean mais conservé comme provenance_unknown.

Le triage d'un verdict fort suit approximativement la priorité suivante.

1. si la provenance n'est pas fiable, provenance_unknown,
2. si le dépôt ou la cible est dirty, dirty_tree_suspect,
3. si une CVE liée ou un marqueur non nié existe, ou si un commit désigné par la réponse comme correctif/relation upstream est un ancêtre du HEAD actuel, known_issue,
4. sinon, new_candidate.

Les expressions de négation ou de non-relation comme « not a known issue », « unrelated to CVE-… » ne sont pas utilisées comme base de known. La décision finale conserve le verdict d'origine ainsi que la branche, le HEAD, le statut, l'état dirty, la référence correspondante et la raison.

Actuellement, la classification en buckets sensible à la provenance et l'écrivain JSONL s'appliquent au chemin d'ingest de l'autopilot. Les loop et ingest manuels utilisent le même état de session de base et le même parseur de verdict, mais ne produisent pas d'artefact de bucket.

V. Implémentation et utilisation

A. Prérequis

• Python 3.11 ou supérieur
• Arborescence source du noyau Linux
• Git pour l'utilisation de provenance/doctor/autopilot
• CLI Codex et authentification pour l'utilisation de l'autopilot [3]
• Connexion réseau pour la collecte syzbot à distance

La dépendance d'exécution Python ne comprend que la bibliothèque standard.

B. Installation

Les profils JSON intégrés sont inclus dans la wheel. Des règles supplémentaires peuvent être transmises via --config /path/to/profile.json.

C. Workflow minimal

Les réponses Codex manuelles sont enregistrées dans codex_response.txt comme spécifié par le runbook, puis peuvent être ingérées avec la commande suivante.

D. Autopilot à budget de temps

La valeur par défaut du sandbox Codex est read-only. --require-clean-tree n'autorise l'exécution que si le dépôt Git, le statut et le HEAD sont confirmés et que l'arbre de travail est clean. --stop-on-finding s'arrête uniquement lorsque le résultat du triage heuristique est new_candidate.

E. Flux syzbot optionnel

F. Artefacts de session

AUTOPILOT_FINDINGS.jsonl conserve le verdict, le bucket, la raison, la branche, le HEAD, l'état de provenance, la référence correspondante et les chemins finding/archive dans un format post-traitable.

VI. Résultat opérationnel et vérification

v2 a appliqué l'architecture étendue à une recherche réelle de vulnérabilités dans le noyau Linux.

TABLEAU II — RÉSULTAT DE VULNÉRABILITÉ PUBLIÉE

Les 16 tests de régression se concentrent sur le contrat logiciel et la déployabilité, et non sur un benchmark de précision de détection de sécurité.

• Régression des ressources de l'allocateur et des profils intégrés
• Vérification que les verdicts négatifs et les expressions CVE en prose générale ne sont pas inversés en findings forts
• Limitation des suivis manuels et ordre de classement
• Archivage des réponses périmées sans cible en attente
• Valeur par défaut du sandbox read-only et argument CLI positif
• Provenance fail-closed pour dépôt manquant/non-Git/échec de statut
• Triage des cibles dirty, références connues, négations et CVE non liées
• Conservation de l'historique de session et du JSONL des métadonnées de classification
• Contrat des artefacts d'erreur de parsing et de finding
• Test de fumée de scan de profil depuis la wheel installée

GitHub Actions exécute les tests de régression sur Python 3.11 et 3.12, installe la wheel, puis effectue un test de fumée sur les 6 profils packagés et un scan par défaut. Le cas public ci-dessus est un résultat opérationnel issu d'une recherche réelle, mais ne constitue pas un benchmark de précision, de rappel, d'exploitabilité ou de taux de découverte de CVE mesuré sur un corpus d'arbres Linux représentatifs.

VII. Considérations de sécurité

• La valeur par défaut du sandbox Codex est read-only et il est recommandé de la conserver.
• Si une provenance clean est importante, utilisez doctor puis --require-clean-tree.
• N'interprétez pas un dépôt non-Git ou un échec de confirmation du statut/HEAD comme clean.
• --dangerously-bypass-approvals-and-sandbox ne doit pas être utilisé en dehors d'un environnement expérimental isolé.
• Les commentaires source et les identifiants étant également des entrées du modèle, tenez compte du risque d'injection de prompt.
• Les chaînes CVE et commit ne sont que des références de réponse, pas une confirmation faisant autorité.
• Avant toute divulgation ou rapport de finding, un humain doit revalider l'atteignabilité, l'invariant, l'impact et la version affectée.

VIII. Limites et menaces à la validité

1. Analyse lexicale. Aucun AST C réel, graphe d'appels ni flux de données interprocédural n'est construit.
2. Biais de score. Les commentaires, macros, tokens répétés et fichiers volumineux peuvent influencer excessivement le score.
3. Écart d'atteignabilité. La configuration du noyau, les privilèges, les namespaces et la disponibilité des périphériques ne sont pas modélisés automatiquement.
4. Fragilité des données externes. L'intégration syzbot est affectée par les changements de structure du HTML public.
5. Provenance locale uniquement. L'ascendance Git est basée sur le HEAD du checkout actuel et ne représente pas tout l'historique upstream et des fournisseurs.
6. Références dérivées de la réponse. Les CVE et marqueurs connus étant extraits de la réponse du modèle, des omissions, hallucinations ou malentendus contextuels sont possibles.
7. Triage heuristique. Ni new_candidate ni known_issue ne constituent un jugement final de nouveauté.
8. Dépendance au modèle. La qualité des résultats dépend du modèle, de l'interprétation du prompt et du contexte du dépôt disponible.
9. Périmètre d'évaluation. Les tests actuels vérifient la régression logicielle. Le cas CVE publié est un résultat d'utilisation réelle mais ne remplace pas une évaluation statistique des performances de détection de sécurité.

IX. Évolution et rétrospective

v1 (dépôt) s'est concentré sur le problème de l'allocation de l'attention du LLM par signal externe et a été utilisé dans une investigation réelle assistée par v1 pour découvrir CVE-2026-31720. v2 poursuit la même philosophie de recherche en étendant l'enregistrement de l'état du dépôt et des références dérivées de la réponse même après qu'un modèle a émis un finding fort. Une investigation ultérieure utilisant cette structure a conduit à la découverte de CVE-2026-53075.

Deux principes doivent être maintenus dans cette évolution.

1. Ne pas interpréter le score pré-inférence comme une preuve de vulnérabilité.
2. Ne pas interpréter le bucket post-inférence comme une preuve de nouveauté.

Si une nouvelle extension était entreprise, la priorité irait au graphe d'appels Clang/tree-sitter, à la normalisation des scores, au manifeste versionné avec verrouillage d'état inter-processus, à un adaptateur de base de données CVE/correctif faisant autorité, et à la séparation du runner, du triage et de l'écrivain d'artefacts. L'écriture d'état actuelle utilise un fichier temporaire et un remplacement atomique.

X. Conclusion

Kernel Codex Harness v2 ne remplace pas la détection de vulnérabilités. Avant l'appel au modèle, le signal externe répartit le budget d'investigation sur des candidats explicables ; après l'appel au modèle, le signal de provenance organise les findings forts en files revoyables. Cette structure a été utilisée dans une recherche réelle pour découvrir CVE-2026-53075, et le résultat clé du projet n'est pas un algorithme de jugement automatique de nouveauté, mais un workflow de revue de sécurité LLM en conditions réelles qui sépare explicitement l'allocation de l'attention et le triage sensible à la provenance.

Annexe A. Structure du dépôt

Les opérations manuelles détaillées sont décrites dans le guide CLI Codex, l'exécution automatique et le triage dans le guide Autopilot, et l'intelligence sur les crashes dans le guide syzbot.

Références

[1] Protect AI, « vulnhuntr », dépôt GitHub. https://github.com/protectai/vulnhuntr

[2] Google, « syzkaller and syzbot », dépôt GitHub. https://github.com/google/syzkaller

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

Licence

Sous licence Apache 2.0.