Index Terms— Linux kernel, vulnerability research, external signal, LLM orchestration, heuristic prioritization, syzbot, program analysis, Codex.

I. Introduction

La revue de sécurité du noyau Linux comporte deux types de problèmes d'échelle. Premièrement, l'arborescence source complète est trop vaste pour tenir dans un seul contexte LLM. Deuxièmement, des signaux comme copy_from_user, les allocateurs, les refcounts et les verrous sont fréquents mais ne signifient pas en soi une vulnérabilité. L'analyste doit d'abord décider « où regarder », puis prouver séparément l'atteignabilité depuis l'userspace et les transitions d'état concrètes.

La philosophie centrale de ce projet est l'External Signal.

On ne laisse pas le LLM décider lui-même où regarder. Des signaux reproductibles, extérieurs à l'inférence du modèle, répartissent l'attention, mais la conclusion de vulnérabilité ne se fonde que sur l'atteignabilité et les preuves d'invariant.

Le harnais ne fait donc pas explorer tout le noyau au modèle de manière vague. Il hiérarchise les fichiers, ne fournit qu'une seule branche d'investigation à la fois et exige d'abord une structure de preuve plutôt qu'une conclusion.

II. External Signal and Design Principles

A. External Signal Before Model Inference

L'External Signal n'est pas un jugement généré par le LLM, mais une observation déterminée avant l'exécution du modèle et recalculable à partir de la même arborescence source, du même profil et des mêmes JSON syzbot stockés. Les poids de chemins, les correspondances d'expressions régulières et le chevauchement syzbot en cache en font partie. Ce signal sert uniquement au classement des candidats et au contexte des prompts ; il n'est jamais promu au rang de verdict ou de preuve.

Dans ce document, l'External Signal désigne la philosophie globale du projet. Le modèle de données ExternalSignal dans le code ne représente actuellement que les signaux issus de syzbot ; les deux termes ont donc des portées différentes.

B. Prioritization Is Not Proof

Les correspondances d'expressions régulières, les chemins à haut risque et le chevauchement syzbot sont tous des signaux destinés à ordonner l'investigation. Un score élevé ne constitue pas un résultat de sécurité si le chemin d'appel réel, les privilèges, la configuration du noyau, le namespace ou la disponibilité des périphériques ne permettent pas à un attaquant d'y accéder.

C. Reachability Before Bug Class

L'audit vérifie d'abord les frontières partant de l'userspace : syscall, ioctl, netlink, procfs, systèmes de fichiers, BPF, hooks de pilotes. Ce n'est qu'ensuite qu'il évalue les classes de bugs telles que UAF, OOB, refcount, course (race), fuite d'informations ou vérifications de capacités.

D. One Investigation Branch at a Time

Une unité d'investigation est par défaut limitée à un seul fichier et à ses chemins proches d'appelants, de teardown et de libération. Les suivis manuels recommandés par le modèle sont limités à deux au maximum. Cette restriction ne vise pas à réduire la capacité d'exploration, mais à maintenir les conclusions dans un périmètre vérifiable.

E. Evidence Over Confidence

Les prompts exigent qu'un résultat fort décrive au minimum les éléments suivants.

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 est rompu,
4. un impact concret : corruption, fuite, élévation de privilèges, etc.,
5. la raison pour laquelle les vérifications existantes ne bloquent pas l'attaque.

Si les preuves sont insuffisantes, le modèle renvoie une seule cible à vérifier ensuite au lieu d'affirmer fortement une vulnérabilité. Il s'agit d'un contrat de preuve au niveau du prompt ; le parseur actuel ne vérifie pas automatiquement l'exhaustivité de chaque preuve. L'ingestion normalise le verdict et la cible suivante ; la validation finale des preuves reste donc de la responsabilité humaine.

F. Design Lineage

Le flux d'investigation initial s'inspire des idées d'analyse par fichier, d'extension limitée du contexte et de résultats structurés utilisées par vulnhuntr de Protect AI [1]. Ce projet ne les applique pas telles quelles à l'analyse d'applications Python, mais les reconçoit autour de la surface du noyau atteignable depuis l'userspace, de la durée de vie des objets du noyau, des chemins de teardown et du chevauchement syzbot. En particulier, séparer les signaux de priorisation de la preuve de vulnérabilité et vérifier l'atteignabilité avant la classe de bug constitue le choix de conception central du harnais pour le noyau.

III. System Architecture

Fig. 1. La couche External Signal transforme les observations calculées avant l'inférence du modèle en unités de revue classées. Elle répartit l'attention mais n'établit pas la preuve d'une vulnérabilité.

TABLEAU I — RESPONSABILITÉS DES MODULES PRINCIPAUX

IV. Methodology

A. Candidate Discovery and Scoring

Le scanner parcourt les fichiers .c et .h situés sous le répertoire d'inclusion du profil. Le score de priorité d'un fichier f se compose conceptuellement comme suit.

Ce score n'est ni une probabilité ni une mesure d'exploitabilité. Chaque terme ne fournit qu'un ordre relatif pour décider quels fichiers le modèle doit examiner en premier. L'implémentation actuelle additionne toutes les correspondances au niveau des lignes et ne limite que les signaux les plus importants affichés dans le prompt. Le recalcul d'un même résultat suppose la même arborescence source, le même profil et les mêmes JSON syzbot en cache. Le poids syzbot est appliqué a posteriori aux fichiers déjà candidats via les heuristiques de chemins et de lignes ; une simple correspondance syzbot ne crée pas de nouveau fichier candidat.

Les principaux signaux statiques sont les suivants.

• ioctl, gestionnaires compat, hooks d'opérations de fichiers
• copy_from_user, copy_to_user, __user
• kmalloc, kzalloc, kvmalloc, chemins d'allocation et de libération de cache
• opérations refcount, atomic, kref
• calculs de taille·longueur et familles memcpy
• motifs liés aux verrous, RCU et durée de vie asynchrone
• frontières BPF, skb, XDP, netlink
• vérifications de capacités et de namespaces

B. Profile-Driven Scope

Les profils intégrés sont default, net, fs, io_uring, bpf et drivers. Un profil définit les chemins d'inclusion, les motifs, les poids et le nombre de signaux à conserver par fichier. Plutôt qu'une politique de score unique pour tout le noyau, chaque profil reflète la surface d'attaque et les caractéristiques de durée de vie propres à un sous-système.

C. Crash Intelligence

syzbot-fetch extrait des pages publiques de bugs syzbot du projet syzkaller [2] le titre, le sous-système, le type de bug et les informations file:line, puis les stocke dans un cache JSON. Un chevauchement exact de fichier constitue un External Signal fort ; un chevauchement de sous-système, un External Signal faible. Le tableau de bord en direct pouvant changer, l'unité de reproduction est le JSON stocké au moment de la collecte. Les informations de crash ne servent que de point de départ pour la chasse aux variantes et ne sont pas traitées comme une preuve de nouvelle vulnérabilité.

D. Session and Review Contract

scan génère un manifeste de candidats classés et un ensemble initial de bundles de prompts. Chaque prompt contient le chemin cible, la raison du score, les signaux de lignes, le contexte syzbot et la procédure d'audit.

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 réponse comprend une Single best next target et un court résumé. Les anciennes réponses sans cible en attente sont archivées séparément et ne sont pas reliées à une nouvelle cible.

V. Implementation and Usage

A. Requirements

• Python 3.11 ou supérieur
• Codex CLI [3] et authentification pour l'autopilote
• Connexion réseau pour la collecte du tableau de bord syzbot distant

B. Installation

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

C. Minimal Workflow

--limit définit le nombre de candidats conservés dans le manifeste et --top le nombre de bundles de prompts pré-générés au départ. Les bundles des rangs suivants peuvent être générés à la demande.

D. Time-Budgeted Autopilot

Le sandbox par défaut est read-only. --sandbox workspace-write ne doit être spécifié que si la modification de fichiers est absolument nécessaire pendant l'analyse.

E. Optional syzbot Feed

F. Session Artifacts

VI. Operational Outcome and Verification

Cette version ne s'est pas limitée à une preuve de concept ; elle a été utilisée pour une véritable recherche de vulnérabilités dans le noyau Linux.

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

La vérification ne constitue pas un benchmark de précision de détection, mais se concentre sur les régressions de l'implémentation et sa déployabilité.

TABLEAU III — PÉRIMÈTRE DE VÉRIFICATION TECHNIQUE

GitHub Actions exécute les régressions unitaires, puis installe la wheel dans un nouvel environnement et effectue un smoke-test du scan avec le profil default. Le cas public ci-dessus est un résultat opérationnel obtenu lors d'une investigation réelle, mais il ne s'agit pas d'un benchmark de précision, de rappel ou de taux de découverte de CVE mesuré sur un corpus représentatif d'arbres Linux.

VII. Safety Considerations

• Il est recommandé de conserver le sandbox read-only par défaut.
• Dans un environnement sans sandbox externe, ne pas utiliser --dangerously-bypass-approvals-and-sandbox.
• Les commentaires et identifiants de source non fiables pouvant devenir des entrées du modèle, il faut tenir compte de l'injection de prompts.
• Les résultats générés par le modèle doivent être revalidés par un humain quant à l'atteignabilité et à l'impact avant toute divulgation ou rapport.
• Les crashes syzbot et les scores heuristiques élevés ne doivent pas être cités comme preuve de vulnérabilité.

VIII. Limitations and Threats to Validity

1. Analyse lexicale. Aucun AST C réel, graphe d'appels ou flux de données interprocédural n'est construit.
2. Biais de score. Les commentaires, macros, jetons 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 dépend des changements de structure du HTML public.
5. Dépendance au modèle. La qualité des résultats dépend du modèle utilisé, de l'interprétation des prompts et du contexte du dépôt.
6. Périmètre d'évaluation. Les tests actuels vérifient les régressions logicielles. 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. Retrospective

Depuis la première version consignée dans l'historique Git, l'objectif était moins de « laisser le LLM trouver les vulnérabilités tout seul » que de « contrôler quel code examiner en premier et quelles preuves exiger ». L'investigation assistée par v1 qui a découvert CVE-2026-31720 a fourni un cas d'application réelle de l'unité d'investigation restreinte et du contrat de preuve. La v2 étend ce workflow jusqu'à un triage sensible à la provenance, qui préserve à la fois l'état du dépôt et les références connues. Si je devais le réimplémenter aujourd'hui, je donnerais la priorité à ce qui suit.

1. un graphe de symboles ou d'appels basé sur tree-sitter ou Clang,
2. une normalisation des scores tenant compte de la taille des fichiers et des correspondances répétées,
3. la suppression des doublons CLI/autopilote via une séparation des couches review et runner,
4. un manifeste versionné et des écritures d'état atomiques,
5. des réponses de modèle et des preuves structurées basées sur un schéma JSON,
6. la liaison automatique des crashes syzbot, des commits de correction et des variantes proches.

Le principe central que je souhaite néanmoins conserver est l'External Signal. Ne pas laisser le LLM explorer vaguement toute la base de code, mais répéter des unités d'investigation restreintes par des signaux extérieurs au modèle, centrées sur l'atteignabilité et les invariants.

X. Conclusion

Kernel Codex Harness ne remplace pas la détection de vulnérabilités du noyau Linux. Il transforme plutôt l'External Signal en un classement explicable et limite la revue LLM à un processus d'investigation court et avec état. Cette structure a été utilisée lors d'une investigation réelle pour découvrir CVE-2026-31720. Le résultat central du projet ne consiste pas à revendiquer un nouvel algorithme d'analyse, mais à définir la revue de sécurité par LLM comme un problème d'allocation d'attention par signaux externes, de contrat de preuve et d'orchestration reproductible, puis à l'appliquer à un workflow de recherche réel.

Appendix A. Repository Layout

Les procédures opérationnelles détaillées sont disponibles dans docs/.

References

[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/

License

Sous licence Apache License 2.0.