Greg Kroah-Hartman dépouille les 79 failles de l’IA dans Linux : dix seulement sont réelles

Fin septembre 2026. Greg Kroah-Hartman, mainteneur des versions stables du noyau Linux, monte sur scène à Kernel Recipes, à Paris, pour une conférence intitulée « Security in the LLM age ». 79. C’est le nombre de vulnérabilités que l’outil IA d’Anthropic prétendait avoir trouvées dans Linux. 10. C’est le nombre de corrections réelles que Kroah-Hartman retient après avoir dépouillé le rapport ligne par ligne. Pourquoi c’est important : le noyau émet désormais 33 CVE par jour contre 50 par semaine un an plus tôt, et le délai moyen entre divulgation et exploitation est passé en territoire négatif — l’adversaire est plus rapide que le correctif.

79 failles annoncées, dix corrections réelles

Le cœur de la conférence est un travail de comptable appliqué à du marketing. Anthropic avait annoncé que son outil avait découvert 79 vulnérabilités dans Linux. Kroah-Hartman a obtenu le rapport complet et l’a trié catégorie par catégorie.

Le décompte est accablant. 24 signalements n’avaient « aucun détail » au-delà de « quelque chose a planté ». 14 n’étaient pas des bugs. 3 étaient des données inventées — il évite le mot « hallucination », qui suppose une entité derrière la sortie. 15 étaient déjà corrigés dans la dernière version, dont 11 par d’autres personnes avant même la publication du rapport : l’outil avait aspiré les listes de diffusion. « Ces outils veulent vous faire plaisir », résume-t-il. « Demandez un bug, et il travaillera très dur pour vous en donner un — y compris celui de quelqu’un d’autre. »

Restent les cas réellement techniques : 7 supposaient une image de système de fichiers malveillante montée par root — le non-bug de sécurité par excellence, auquel l’équipe sécurité du noyau a une réponse toute prête. 2 supposaient une injection de paquets au milieu de la pile. 2 étaient des bugs NOMMU, qu’il a corrigés en notant au passage que personne ne fait tourner io_uring sur un système sans MMU. 6 concernaient SCTP sur des réseaux télécom authentifiés, 2 de petits problèmes IPv6, et 1 exigeait un utilisateur local malveillant avec un accès GPU.

Le total final : dix corrections réelles. Le noyau fusionnant environ 10,5 correctifs par heure, l’opération marketing tout entière équivaut à « une heure de développement du noyau ». Kroah-Hartman crédite tout de même l’infrastructure autour du modèle, qui lui a construit une VM RISC-V NOMMU, un cas de test et un script Perl reproduisant le bug io_uring.

Le vrai signal : un délai d’exploitation négatif

La diapositive qui devrait inquiéter ne parle pas de comptage de bugs. Le délai moyen entre divulgation et exploitation était de 63 jours en 2018, 32 en 2020, 5 en 2024 — et il est désormais de moins sept jours. Le cycle « découvrir, divulguer, corriger, déployer » « a été conçu pour un adversaire plus lent, et cet adversaire n’existe plus ».

Les LLM sont « bêtes mais persistants », et la persistance leur permet d’enchaîner plusieurs failles mineures en un accès réel. Conséquence : les correctifs mineurs comptent, et il faut prendre les mises à jour stables. « La facture finit par arriver », lâche-t-il — tout en notant qu’il voit des banques s’engager à mettre à jour leurs logiciels, ce que les développeurs du noyau demandent depuis quinze ans.

Il reste optimiste sur l’issue. La vague des fuzzers d’il y a six ou sept ans avait produit les mêmes discours de fin du monde, et la réponse a été de s’asseoir et d’épuiser les bugs un à un. Andrew Tridgell a fait exactement cela avec rsync à l’aide de ces outils, et la dernière version passe désormais au scan sans tache.

La moitié des correctifs d’IA sont faux

L’autre moitié du problème, c’est la qualité des correctifs que l’IA génère. Cet été, Kroah-Hartman a demandé à six doctorants de la VU Amsterdam de passer en revue un large ensemble de correctifs de sécurité générés par LLM. Environ la moitié étaient « franchement faux » : ils ne s’appliquaient pas, ne corrigeaient rien, visaient un problème inexistant ou un chemin inatteignable, ou n’étaient pas des problèmes de sécurité même selon le modèle de menace documenté. Un seul l’a trompé.

Les schémas d’échec se répètent. Le plus courant remplace mutex_unlock() par mutex_destroy(), apparemment parce que « destroy » sonne plus complet — et cela casserait des choses. Les correctifs générés arrivent avec des changelogs énormes et sept lignes de commentaires pour deux lignes de code. Entraînés sur des décennies d’archives, ils reproduisent d’anciens styles de code et d’anciennes failles, et un des bots a même juré. La parade des étudiants : supprimer le changelog et juger le code seul.

Il prévient aussi que les bots fuient : tout ce qui est téléversé finit chez quelqu’un d’autre. Et il rappelle l’histoire de Coverity — les développeurs n’ont jamais toléré un taux de faux positifs au-delà de 20 %, et un taux de 50 % ne se vendra pas.

Ce que le noyau a changé

Le noyau a tiré des conséquences concrètes. Il a documenté son modèle de menace par sous-système — les gens qui font tourner les bots le lisent parfois —, demande aux signalants de mettre les mainteneurs en copie pour répartir la charge, et préfère un correctif à un rapport, ce qui réduit le bruit tout en flattant le désir de crédit du signalant. OpenSSF et Alpha-Omega financent désormais un développeur à temps plein sur l’outillage de sécurité de kernel.org.

Sa liste pour les développeurs tient en cinq points : repousser tout ce qui semble faux, en demandant comment cela a été testé ; ignorer le marketing de fin du monde ; faire tourner des modèles locaux ; ne jamais téléverser d’information non publique ; corriger les bugs d’aujourd’hui plutôt que d’attendre le modèle de demain. En questions-réponses, il précise qu’il a banni les correctifs LLM de drivers/staging sauf si l’auteur possède le matériel et l’a testé — la zone existe pour apprendre le développement noyau, pas pour le sous-traiter. Son estimation de la durée du raz-de-marée : « environ dix-huit mois, peut-être douze ».

Verdict

Si vous maintenez un projet open source, retenez les deux chiffres : un rapport IA contient en moyenne moins de 13 % de vraies corrections, et un correctif IA est faux une fois sur deux — la revue humaine reste le goulot, et le réflexe utile est de demander « comment l’avez-vous testé ? » avant de lire le code. Si vous exploitez des systèmes Linux en production, la leçon est plus urgente et ne dépend pas des bots : le délai d’exploitation est négatif, donc la fenêtre entre « correctif publié » et « correctif déployé » est votre seule marge — appliquez les mises à jour stables dès leur sortie, sans les trier à la main. Dans les deux cas, n’achetez pas le récit du « modèle qui trouve des failles » sans le décompte derrière : la valeur de ces outils est réelle, mais elle se mesure en une heure de travail de mainteneur, pas en marketing.

Références

• Sparse Notes — Security in the LLM Age (Greg Kroah-Hartman, Kernel Recipes 2026), octobre 2026
• Kernel Recipes — Security in the LLM age, session 2026
• HKLUG — Kernel maintainers triage a surge of LLM bug reports, 1er octobre 2026
• Braindetox — How a kernel maintainer read the LLM era (CVE counts vs. real bugs), septembre 2026