Greg Kroah-Hartman prévoit un cycle Linux 7.3 difficile sous le flot des patchs IA

2 septembre 2026. Greg Kroah-Hartman, numéro deux du noyau Linux, avertit sur social.kernel.org que le cycle 7.3 « va être un cycle -rc difficile ». 1732 messages. C’est le volume de sa file « à traiter » pour le seul sous-système USB — réduit à 1094 après un premier tri des correctifs évidents. 18 octobre 2026. Date visée pour la sortie stable de Linux 7.3, repoussée au 25 octobre si la fin de cycle tourne mal. Pourquoi c’est important : le goulot d’étranglement du noyau n’est plus le code, mais la capacité de relecture humaine face à un afflux de patchs produits par l’IA.

Une boîte de réception qui déborde

Le signal est chiffré, et il est brutal. Greg Kroah-Hartman montre sa file todo pour linux-usb : [Msgs:1732/4807 Inc:2 78M]. Après un premier passage sur les correctifs « faciles » — ceux qui réparent un bug évident ou dont une version plus récente a remplacé une soumission antérieure — il reste [Msgs:1094/4170 Inc:2 69M]. « Toujours dément », commente-t-il.

La cause est nommée : les développeurs du noyau sont bombardés de patchs de correction générés par IA, « certains authentiques, d’autres moins utiles », qui touchent souvent des portions de code inactives depuis des années ou des pilotes obsolètes. Une « énorme majorité » des soumissions actuelles provient d’outils d’analyse statique qui « trouvent de très vieux détails mineurs, déclenchables uniquement si on tient le code d’une certaine façon ».

Le plus frappant est la prudence du mainteneur. Il « repousse » régulièrement les soumissions IA, mais refuse de rejeter en bloc ce qui est « manifestement un correctif ». « Refuser “c’est évidemment un bugfix” est difficile, et je ne veux pas le faire — cela prendra juste du temps de tout trier. » Sa conclusion sonne comme un avertissement : « Comme je le dis depuis des mois en conférence, ça va être un long 18 mois, et ce chiffre ne semble pas diminuer. »

Le vrai goulot d’étranglement n’est plus le code

Ce qui change, c’est la nature du travail de maintenance. Historiquement, la limite d’un cycle de développement était la production de correctifs : peu de gens écrivaient du code pour les pilotes vieillissants. Aujourd’hui, la limite est la relecture. Une machine produit du code plus vite qu’un humain ne peut le juger, et chaque patch IA exige une vérification que l’auteur humain aurait fournie lui-même en l’écrivant.

Le noyau a déjà répondu à l’endroit où il le pouvait. Pour la zone staging, dont Greg Kroah-Hartman a aussi la charge, une politique refuse les patchs IA à l’exception des vrais correctifs de sécurité. Ailleurs, la réponse est plus artisanale : trier, repousser, accepter les évidences, et encaisser le surcoût de temps. Le résultat est un cycle 7.3 qui démarre déjà lourd, alors même qu’il n’en est qu’au tout début de la phase -rc.

Près de 2 000 CVE par release

Le flot de correctifs a une traduction directe dans les chiffres de sécurité. En avant-première de sa conférence Kernel Recipes 2026 (Paris, du 21 au 23 septembre), Greg Kroah-Hartman a montré l’évolution des CVE corrigées par release. De Linux 6.9 à 6.19, le noyau tournait autour de 500 CVE par release. Depuis Linux 7.0, il dépasse le millier ; 7.2 a franchi les 1 500, et 7.3 pourrait dépasser les 2 000.

La nuance est essentielle, et Phoronix la souligne : la plupart de ces CVE sont de faible gravité, souvent situées dans des pilotes anciens ou obscurs, « l’impact est souvent minime ». Le code source du noyau approchant les 40 millions de lignes — 7.3-rc1 pèse 40,98 millions de lignes, soit 560 000 de plus que 7.2 — le réservoir de failles potentielles que les LLM peuvent signaler est immense.

Ce qu’il faut en retenir n’est pas que le noyau devient plus dangereux, mais que le signal CVE se dilue. Quand une release corrige 2 000 entrées dont la majorité sont inexploitables en pratique, trier les vraies urgences devient un travail à part entière.

Ce que ça change pour ceux qui consomment le noyau

Pour une distribution, l’équation est connue : backporter les correctifs de sécurité vers ses noyaux stables, sans importer le bruit. L’inflation des CVE rend ce tri plus coûteux, pas plus simple. Pour une équipe d’infrastructure, la conséquence est inverse de l’intuition : il devient moins rentable de courir après chaque CVE noyau signalée, et plus rentable de s’appuyer sur les trains stable et LTS que les mainteneurs tiennent à jour.

La bonne pratique ne change pas, mais elle devient plus exigeante. Mettre à jour son noyau en continu, privilégier les versions stable/LTS, et traiter les CVE à CVSS élevé ou exploitées en priorité. Le reste — les centaines de défauts mineurs dans des pilotes que personne n’utilise — se règle par la mise à jour régulière, pas par une course individuelle.

Ce que 7.3 contient, sous le bruit

Derrière le tumulte des correctifs, 7.3 apporte de vraies nouveautés : le support initial d’AMD Zen 6, des optimisations Btrfs, et le contrôleur Steam 2026, pour ne citer que ce que Phoronix a relevé à la sortie de 7.3-rc1. La taille du cycle — 560 000 lignes ajoutées, pour un arbre de 40,98 millions de lignes — est à la fois une promesse de fonctionnalités et un réservoir de bugs supplémentaires à trier.

C’est là que la mécanique devient circulaire : plus le noyau grossit, plus les outils d’analyse trouvent de défauts, plus le flot de correctifs gonfle, plus la relecture ralentit. Greg Kroah-Hartman l’a résumé en une image : sa file todo ne désemplit pas. La réponse à long terme n’est pas plus de mainteneurs — ils ne se décrètent pas — mais des politiques de tri plus strictes, comme celle déjà appliquée à la zone staging.

Le rôle exact du second du noyau

Un mot de contexte pour mesurer l’alerte. Greg Kroah-Hartman n’est pas un contributeur parmi d’autres : il maintient les branches stable, supervise le sous-système USB et la zone staging, et porte une part démesurée de la charge de relecture quotidienne. Quand il parle d’un cycle « difficile », ce n’est pas une opinion de blogueur — c’est le diagnostic de l’homme qui trie, littéralement, des milliers de messages par cycle.

Cette concentration de charge est elle-même un risque. Le jour où le goulot humain cède, ce n’est pas un pilote qui souffre, mais la cadence des correctifs de sécurité de tout l’écosystème. C’est pourquoi la question du flot de patchs IA n’est pas une anecdote de couloir : elle touche à la soutenabilité du modèle de maintenance du noyau.

Verdict

Si vous maintenez un noyau ou une distribution, anticipez : le cycle 7.3 sera long, la sortie stable se jouera entre le 18 et le 25 octobre, et le volume de CVE va continuer de grimper. Investissez dans le tri automatisé du flux CVE plutôt que dans la relecture manuelle de chacune.

Si vous exploitez des serveurs, restez sur les trains stable et LTS, mettez à jour en continu, et ne traitez individuellement que les CVE réellement exploitables ou à fort CVSS. Le bruit des 2 000 CVE ne doit pas dicter votre cadence.

Dans tous les cas, l’alerte de Greg Kroah-Hartman est un signal d’écosystème : la relecture humaine est devenue la ressource rare du noyau. Un patch de plus n’est plus une contribution — c’est un coût de relecture.

Références

• Phoronix — Greg KH Forewarns Of “Rough” Linux 7.3 Kernel Cycle Due To Continued AI Churn, 2 septembre 2026
• Phoronix — The Linux Kernel Is Approaching 2,000 CVEs Per Release, 28 août 2026
• Phoronix — Linux 7.3-rc1 With AMD Zen 6 Additions, Better Btrfs Performance, 30 août 2026
• Phoronix — Linux 7.3-rc1 Close To 41 Million Lines, 1 septembre 2026
• Kernel Recipes 2026 — Paris, 21–23 septembre 2026