Le noyau Linux voit affluer un nombre record de CVE corrigés par version, non en raison d’une baisse de sécurité mais parce que des outils d’intelligence artificielle parcourent ses 40 millions de lignes. Les mainteneurs disent être submergés, face à un flux massif de correctifs souvent mineurs.
Greg Kroah-Hartman affiche les chiffres: 1 000 puis 1 500, cap sur 2 000
Greg Kroah-Hartman a présenté une diapositive pour Kernel Recipes 2026 montrant que Linux 7.0 franchissait le seuil des 1 000 CVE attribués, que Linux 7.2 dépassait les 1 500, et que la trajectoire de Linux 7.3 pourrait atteindre les 2 000.
Ces chiffres couvrent les CVE corrigés par version, c’est-à-dire des correctifs déjà intégrés aux branches stables. Le total n’indique pas une explosion d’exploits actifs, mais une hausse des signalements détectés par des outils automatisés.
La base de code du noyau, avec plus de 40 millions de lignes accumulées en 35 ans, offre un vaste terrain pour les grands modèles et autres analyseurs statiques. Les mainteneurs notent que la cadence de CVE a évolué drastiquement depuis la série 6. x, où environ 500 CVE par version étaient la norme.
Pourquoi l’IA produit un tsunami de CVE sans dégrader la sécurité
La cause principale tient à la méthode: des chercheurs équipés d’outils d’IA scandent l’arborescence du code et signalent des anomalies susceptibles d’entraîner des CVE. Le noyau, pour sa part, attribue systématiquement un CVE à un correctif qui modifie la stabilité ou l’accès mémoire, sans évaluer l’exploitabilité.
Autrement dit, l’attribution d’un CVE survient souvent après le développement du patch dans le flux de travail du noyau, et non en amont comme dans l’industrie. Cette inversion de procédure augmente mécaniquement le nombre de CVE publiés.
De plus, les développeurs n’établissent pas de score CVSS, car ils ne connaissent pas tous les contextes d’exécution de Linux. Le nombre élevé reflète donc une pratique conservatrice d’étiquetage plutôt qu’une multiplication réelle d’attaques exploitables.
Mainteneurs débordés: tri administratif, retouches et nettoyages poussés par l’IA
Dans la demande d’intégration réseau de Linux 7.3, Jakub Kicinski a estimé que un tiers à la moitié des 648 correctifs net-next étaient des retouches mineures, nettoyages ou clarifications de faible priorité incitées par l’IA. L’équipe se dit complètement submergée.
Linus Torvalds a qualifié la liste de diffusion sécurité de presque ingérable, les mainteneurs consacrant désormais des journées au tri administratif plutôt qu’à l’élaboration de correctifs profonds. Cette charge pèse sur la capacité à prioriser et tester correctement chaque patch.
Concrètement, cela allonge les délais de revue, complique la rétrocompatibilité et augmente la charge de gestion des backports pour les branches stables, surtout dans les environnements de production exigeant des tests poussés.
Impacts pratiques pour les administrateurs et suggestions de gestion
Pour les équipes IT, le flot de CVE implique un arbitrage entre rapidité et stabilité. Tous les CVE ne valent pas une mise à jour urgente: beaucoup sont des clarifications non exploitables dans des configurations courantes.
Les bonnes pratiques recommandées incluent une politique de test automatisé, un filtrage basé sur l’impact réel (modules utilisés, exposition réseau) et l’application de correctifs critiques en priorité. Les gestionnaires de paquets et distributions renforcent déjà des outils d’évaluation pour hiérarchiser les correctifs.
Un exemple concret: lors de la vague de 432 CVE publiés en 48 heures, plusieurs distributions ont trié les correctifs en trois niveaux, appliquant en production d’abord ceux affectant l’accès mémoire direct et reportant les nettoyages annexes aux cycles de maintenance.
| Élément | 6. x (moyenne) | 7. x (tendance) |
|---|---|---|
| CVEs corrigés par release | 500 | 1 000-2 000+ |
| Taille approximative du code | 40 millions de lignes (total historique) | |
| Part des correctifs IA-induits | Faible | 30-50 % (estimation mainteneurs) |
Que retenir pour l’avenir du développement et de la sécurité du noyau
L’arrivée massive d’outils d’IA change les règles opérationnelles: plus de couvertures de défauts, plus de signalements, mais aussi plus de charge pour les équipes humaines. Les processus de revue et de priorisation doivent évoluer.
Les mainteneurs évoquent des solutions organisationnelles: filtrage automatisé des faux positifs, meilleure qualification des rapports d’IA et renforcement des équipes de revue. Les distributions pourraient aussi jouer un rôle en catégorisant les CVE selon l’impact contexte-dépendant.
La tendance est claire: la surface d’analyse augmente avec les outils modernes, et le projet Linux doit adapter ses pratiques pour transformer ce surplus d’informations en gains de sécurité exploitables sans étouffer ses contributeurs
