foxirain/linux-kernel-codex-harnessHarness de recherche de vulnérabilités du noyau Linux piloté par les preuves, utilisé dans l'investigation de la CVE-2026-31720.
Outil de recherche · Import d'origine : 3 avril 2026 · Révision de la documentation : 11 juillet 2026
Philosophie centrale — Signal externe
Laissez des observations reproductibles calculées en dehors de l'inférence du modèle guider l'attention ; ne confondez jamais priorité et preuve.
État du projet. Ce dépôt est une version initiale d'un harnais de recherche assisté par LLM que j'ai construit et utilisé pour une véritable recherche de vulnérabilités dans le noyau Linux. Cette version a servi à découvrir la vulnérabilité publiée sous le nom CVE-2026-31720. Le harnais hiérarchise les cibles d'investigation mais ne prouve pas automatiquement les vulnérabilités ni ne garantit la sécurité du noyau ; la validation finale et le rapport restent effectués par un humain.
Abstract— Laisser un LLM explorer directement une base de code aussi vaste que le noyau Linux disperse rapidement le contexte et confond facilement la présence d'API dangereuses avec une exploitabilité réelle. Kernel Codex Harness définit ce problème non pas comme de la détection automatique de vulnérabilités, mais comme un problème de priorisation d'investigation et d'orchestration basée sur l'état. Ce projet appelle External Signal le principe consistant à contrôler l'attention du modèle avec des observations reproductibles calculées en dehors de l'inférence du LLM. Il combine des signaux statiques liés aux chemins du noyau, aux frontières userspace, à la durée de vie (lifetime), aux usercopy, aux refcounts et aux tailles, ainsi qu'une intelligence optionnelle des crashes syzbot, pour classer les fichiers candidats et transformer chaque candidat en un ensemble restreint de prompts. La revue manuelle et l'autopilote basé sur un budget de temps utilisent le même contrat de réponse et le même état de session. Ce harnais a été utilisé dans une investigation réelle du noyau Linux qui a découvert un dépassement d'écriture hors limites sur la pile dans le chemin audio du gadget USB ; ce défaut a été publié sous le nom CVE-2026-31720. Cette implémentation n'est pas un analyseur statique de précision, mais un workflow de recherche qui limite le périmètre d'investigation du LLM à l'aide d'heuristiques explicables ; chaque résultat exige une revalidation humaine de l'atteignabilité (reachability), de la rupture d'invariant et de l'impact concret.
Index Terms— Linux kernel, vulnerability research, external signal, LLM orchestration, heuristic prioritization, syzbot, program analysis, Codex.
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.
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.
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.
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.
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.
Les prompts exigent qu'un résultat fort décrive au minimum les éléments suivants.
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.
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.
