Linux 7.3-rc4 bloque les microcodes Granite Rapids dangereux et nettoie les bugs repérés par les LLM
Le 20 septembre 2026, Linus Torvalds a publié Linux 7.3-rc4, un candidat « plus gros que d’habitude » qui rejette un microcode Intel Granite Rapids capable de provoquer des erreurs machine et intègre une vague de correctifs de chemins d’erreur repérés par des LLM. Testeurs sur matériel Intel : mettez à jour sans tarder.
20 septembre 2026. Linus Torvalds publie Linux 7.3-rc4. 30 août 2026. Le cycle 7.3 démarrait avec le premier candidat. 18 octobre 2026. La version stable est attendue si aucun rc8 ne s’impose. Pourquoi c’est important : ce candidat est « plus gros que d’habitude » pour ce stade du cycle, et il corrige à la fois un risque matériel sur les serveurs Intel Granite Rapids et une vague de bugs de chemins d’erreur repérés par des LLM.
Un rc4 anormalement gros
Dans son courriel d’annonce, Torvalds note que la taille du candidat reste « sensiblement plus grande que la normale » pour un rc4. La répartition du code est elle-même inhabituelle : d’ordinaire dominés par les pilotes, les changements se partagent cette semaine en trois tiers quasi égaux — un tiers de pilotes, un tiers de systèmes de fichiers et de réseau, un tiers de divers (correctifs d’architecture, cœur du noyau, outils de développement).
Le plus gros patch de la semaine ne corrige rien : il supprime un fichier restant. Lors de la fenêtre de fusion, lib/alloc_tag.c a été déplacé vers le répertoire mm/, mais la copie d’origine est restée en place jusqu’à son retrait définitif dans ce rc4. Un détail anodin qui illustre la nature du candidat : du nettoyage, en profondeur.
Cette répartition à trois tiers signale un cycle de consolidation plutôt que de nouveauté. Quand les systèmes de fichiers et le réseau pèsent autant que les pilotes, c’est que les mainteneurs traitent des dettes de stabilité accumulées — typiquement les chemins de code rarement exercés que ni les tests ni les utilisateurs ne couvrent. Pour un noyau appelé à porter des serveurs de fichiers et des passerelles réseau en production, c’est précisément le genre de travail qui se voit peu mais qui évite les incidents.
Granite Rapids : le microcode dangereux bloqué
Le correctif le plus décisif concerne Intel Granite Rapids (Xeon 6). Le noyau rejette désormais explicitement les mises à jour de microcode problématiques sur ces serveurs. La révision 0x1000405 apporte des changements internes requis par les révisions suivantes, mais peut provoquer une machine check exception si elle est chargée sur un système non encore passé à 0x1000405.
La page de spécification d’Intel référence l’anomalie sous le nom GNR98, attribuée à l’interface de communication inter-microcode. Une seconde anomalie, GNR101, vient d’une révision minimale d’exécution incorrecte dans la version de microcode 0x1000423. Le noyau bloque donc le chargement de 0x1000405 ou supérieur — en chargement précoce comme tardif — tant que le système n’est pas déjà à jour. Ce correctif est marqué pour rétroportage vers les branches stables existantes.
Le lot x86 règle aussi deux cas de figure plus grand public. Intel FRED sur Panther Lake faisait planter ou geler certains jeux sous Wine et Steam Play : le correctif est intégré. Et les noyaux compilés avec -march=native sur les futures plateformes APX pouvaient employer les registres étendus EGPR (R16–R31) avant que le noyau ne soit prêt — le code bloque désormais cette utilisation jusqu’à la prise en charge d’APX.
Les systèmes de fichiers en première ligne
Les systèmes de fichiers concentrent une part inhabituelle de l’attention du cycle 7.3. NTFS gagne des réservations dynamiques de queue de MFT et des listes d’enregistrements $MFT recompactées, avec de nouveaux verrous pour protéger les mises à jour des listes de fragments contre les courses.
SMB et CIFS reçoivent plusieurs corrections de stabilité : application correcte des règles d’expiration de session SMB2, envoi des accusés de rupture de bail sur la bonne session pour les montages multi-utilisateurs, et correction de fuites mémoire comme d’use-after-free lors du démontage des interfaces. Btrfs restaure des identifiants de système de fichiers stables : f_fsid n’est dérivé de dev_t que lorsqu’un temp_fsid actif existe.
Le reste du noyau suit. SELinux préserve les SID utilisateur à travers les fichiers de support imbriqués et revérifie les fichiers intermédiaires lors des changements de protection mémoire. xfrm sérialise la collecte d’état des déchets. Bluetooth valide les longueurs de données de service avant de lire les UUID dans les en-têtes de paquets. ARM64 clone uniquement la carte linéaire réellement présente au moment de l’hibernation.
Les LLM entrent dans le cycle de correction
L’angle le plus neuf du rc4 est éditorial. Torvalds souligne une poussée de petits correctifs de chemins d’erreur dans de nombreux pilotes, et remarque que les grands modèles de langage semblent « particulièrement efficaces » pour attraper ces défauts obscurs de gestion d’erreur.
La plupart des utilisateurs de bureau ne rencontreront jamais ces chemins d’échec rares. Mais en cas de panne matérielle soudaine ou d’échec d’allocation, ces correctifs évitent des plantages durs et maintiennent le système en marche. C’est la première fois que l’aide des LLM à la chasse aux bugs se lit aussi nettement dans un courriel de release du noyau — un signal à suivre pour les mainteneurs comme pour les équipes qui instrumentent leur propre code.
Ce que cela signifie pour les distributions
Le calendrier donne la feuille de route. rc5 est attendu le 27 septembre, rc6 le 4 octobre, rc7 le 11 octobre, et la version stable le 18 octobre — sauf rc8, qui la repousserait au 25 octobre. Les distributions majeures commencent généralement à intégrer un noyau quelques semaines après sa sortie stable : les correctifs Granite Rapids arriveront donc dans les mises à jour de sécurité des distributions de serveur dans la foulée.
Pour un SRE ou un administrateur système, le réflexe est double. Sur serveur, surveiller le canal de mise à jour de la distribution : le blocage du microcode 0x1000405 sera rétroporté vers les branches stables, et c’est là qu’il comptera le plus, sur du matériel Xeon 6 en production. Sur poste de travail, ne rien faire : les correctifs FRED et APX se propageront avec les noyaux stables des distributions grand public.
Verdict
Linux 7.3-rc4 est un candidat de stabilisation qui corrige des risques concrets, pas des hypothèses. Si vous testez 7.3 sur des serveurs Intel Granite Rapids, mettez à jour immédiatement : le blocage du microcode 0x1000405 prévient une erreur machine possible. Si vous jouez sous Wine sur Panther Lake, ce correctif règle des gels et plantages. Si vous êtes en production, restez sur une branche stable — la version finale est attendue le 18 octobre 2026, sauf rc8 qui la repousserait au 25 octobre. La nouveauté à retenir est ailleurs : les LLM sont désormais une force de correction mesurable dans le cycle du noyau.
Références
- Phoronix — Linux 7.3-rc4 Released: More Fixes Caught By LLMs, But Nothing Too Scary (20 septembre 2026)
- Phoronix — Important x86 Fixes Merged Ahead Of Linux 7.3-rc4 (20 septembre 2026)
- OSTechNix — Linux Kernel 7.3 RC4 Released: Bigger Than Usual With LLM Bug Fixes (21 septembre 2026)
- Announce mail de Linus Torvalds — Linux 7.3-rc4