Linux 7.3-rc4 arrive avec des correctifs trouvés par des LLM

Linus Torvalds a publié Linux 7.3-rc4 le 20 septembre 2026 et a désigné les grands modèles de langage comme une source utile pour un type précis de rapport de bogue. Phoronix le cite disant que "divers LLM semblent plutôt bons pour attraper" les problèmes du code de nettoyage des chemins d'erreur. C'est une affirmation étroite venant du mainteneur le plus ancien du noyau, et elle est plus intéressante qu'une préversion de routine.

Une préversion, ou version candidate, est une compilation de test publiée chaque semaine pendant qu'une version du noyau se stabilise. Torvalds a qualifié celle-ci de "grande", selon LWN, ajoutant que cela n'a rien de surprenant à ce stade du cycle.

Pourquoi les LLM repèrent justement les chemins d'erreur

Le nettoyage des chemins d'erreur est un point faible connu du code C, et le noyau en est rempli. Une fonction prend un verrou, alloue de la mémoire, prend une référence sur un objet, puis échoue en cours de route. Tout ce qui a été acquis doit être libéré, en ordre inverse, avant que la fonction ne retourne.

Le chemin de réussite d'une telle fonction est parcouru en permanence. Les chemins d'échec, eux, ne s'exécutent souvent jamais en usage normal. Une fuite ou un verrou non libéré peut donc y rester des années sans que personne le remarque.

Cette forme explique aussi pourquoi un modèle trouve ces bogues. L'erreur est locale et visible dans une seule fonction : quelque chose a été acquis et n'a pas été libéré. Le relecteur n'a pas besoin de comprendre tout le sous-système, et le modèle non plus. C'est de la reconnaissance de motifs appliquée à une règle que le noyau utilise partout.

L'affirmation est bien plus modeste que de dire qu'un modèle peut écrire du code noyau. Torvalds décrit une catégorie de défaut où le raisonnement est superficiel et le volume de code énorme. C'est exactement la combinaison que l'outillage automatique traite bien depuis toujours.

Ce que contient rc4 par ailleurs

Phoronix indique que les correctifs se répartissent en tiers à peu près égaux : environ un tiers dans les pilotes, un tiers dans les systèmes de fichiers et le réseau, un tiers dans l'architecture et l'outillage.

Domaine	Exemples rapportés
Architecture	Correctifs x86 et x86_64
Systèmes de fichiers	Deux bogues Btrfs, plus des changements SMB et NTFS
Pilotes	Prise en charge de la manette XPad

Un correctif se détache. Phoronix rapporte un patch pour un bogue qui perdait silencieusement des données de l'espace utilisateur, et indique que le défaut était présent depuis 2023. La perte silencieuse de données est la pire catégorie de bogue noyau, car rien n'échoue visiblement sur le moment et les dégâts se découvrent plus tard, si tant est qu'on les découvre.

Le travail sur Btrfs prolonge un fil de ce cycle : des correctifs pour les identifiants de systèmes de fichiers et le démarrage grub2 étaient déjà prévus pour cette même préversion. La version finale de Linux 7.3 est attendue en octobre 2026.

Ce que cela signifie pour les développeurs

Prenez l'affirmation sur les LLM à la taille où elle a été faite. Torvalds a cité le nettoyage des chemins d'erreur, pas la correction en général. Pour reproduire le résultat, pointez un modèle vers vos propres chemins d'échec. Posez-lui une seule question délimitée : chaque retour anticipé libère-t-il ce que la fonction a acquis au-dessus ?

Comparez avec ce que vous exécutez déjà. Le noyau utilise depuis de nombreuses années l'analyse statique pour cette classe de bogues, avec des outils comme Coverity et smatch. La vraie question n'est pas de savoir si les modèles trouvent ces bogues, mais s'ils en trouvent que ces outils manquent, et à quel taux de faux positifs. Aucun de ces articles n'y répond, alors traitez-la comme une question ouverte plutôt que comme une victoire acquise.

Le circuit de signalement compte plus que la trouvaille. Un modèle produit un patch d'apparence plausible aussi facilement qu'un vrai, et un mainteneur ne peut faire la différence qu'en relisant lui-même. Si vous soumettez un correctif trouvé ainsi, vérifiez-le d'abord vous-même et dites comment vous l'avez trouvé. Gardez le patch assez court pour être relu en une seule fois.

Pour qui suit la 7.3, c'est le signal habituel pour commencer à tester. Torvalds a qualifié cette version de grande sans la dire inquiétante. À ce stade du cycle, la forme de la publication est fixée et les semaines restantes servent à la finition. Si vous maintenez des modules hors arbre ou un noyau de distribution, compilez contre rc4 maintenant plutôt que d'attendre octobre. Ubuntu 26.10 livre déjà un noyau 7.3 en préversion, donc certains utilisateurs croiseront ce code avant sa finalisation.

Le bogue de perte de données de 2023 est le rappel concret de cette publication. Un défaut qui jette discrètement des données utilisateur a survécu trois ans dans un noyau lu par plus de monde que presque n'importe quelle autre base de code. C'est un argument pour davantage de vérification automatique des chemins que personne n'exécute, quel que soit l'outil qui s'en charge.