Le noyau Linux 7.2.5 rattrape le pilote Blackwell et durcit ksmbd
Les noyaux stables 7.2.5 et 6.18.51, publiés le 11 septembre 2026, corrigent la sortie vidéo des GPU Blackwell dans nouveau et colmatent une fuite mémoire et un use-after-free dans ksmbd. Mettez à jour en priorité si vous exposez des partages SMB ou utilisez une carte Blackwell.
11 septembre 2026. Greg Kroah-Hartman signe deux versions stables du noyau Linux : 7.2.5 et 6.18.51. Chacune embarque environ 550 correctifs. Septembre 2026. Le gros du volume est dans le pilote nouveau, qui rattrape enfin les cartes Blackwell, et dans le durcissement de ksmbd, le serveur SMB du noyau. Pourquoi c’est important : sous la routine hebdomadaire, ce cycle montre un noyau stable désormais entretenu avec l’aide explicite de l’IA — et deux familles de bugs qui touchent des machines de production réelles.
Deux arbres, une cadence
7.2.5 repose sur la base mainline du 17 août 2026 ; 6.18.51 poursuit la série sortie en décembre 2025 avec son cinquante-et-unième correctif incrémental. Les deux portent la même signature de Greg Kroah-Hartman, le mainteneur des noyaux stables, et suivent le rythme hebdomadaire habituel. Rien de spectaculaire dans le calendrier — c’est justement ce qui rend le contenu instructif.
La branche 6.18 n’a toujours pas été officiellement labellisée LTS, mais cinquante-et-un correctifs stables en neuf mois racontent une réalité différente : la communauté la traite déjà comme une branche de longue durée. Les distributions d’entreprise vont pousser 6.18.51 dans leurs cycles de validation habituels, tandis que les distributions rolling intégreront 7.2.5 à leur prochaine mise à jour. Pour un opérateur, le choix entre les deux tient moins au contenu — quasiment identique — qu’à la politique de support de sa distribution.
Le pilote Blackwell rattrape enfin les registres
Le cluster de correctifs le plus volumineux concerne nouveau, le pilote GPU libre. Les puces GB20x de la génération Blackwell avaient changé la disposition de leurs registres, et le pilote ne suivait pas : les interruptions de synchronisation « head timing » étaient encore routées vers les anciens vecteurs hérités au lieu des nouveaux vecteurs message à faible latence. Conséquence directe : la synchronisation vblank et les requêtes de séquence cassaient.
Ce n’est pas un bug cosmétique. La synchronisation vblank est ce qui aligne le rendu sur le rafraîchissement de l’écran ; sans elle, les compositeurs affichent des images déchirées ou attendent des événements qui ne viennent jamais. Le même cycle corrige des infoframes vidéo HDMI et des erreurs d’alignement de registres sur le même matériel. Pour quiconque débogue une sortie d’affichage sur une station de travail Blackwell avec le pilote libre, c’est le correctif qui fait passer l’écran de « instable » à « exploitable ».
Le détail qui illustre la nature de l’effort est ailleurs : l’un des correctifs nouveau de ce cycle crédite Claude pour avoir aidé à tracer une déréférence de pointeur NULL dans le code UVMM. On n’est plus dans l’anecdote — l’IA devient un contributeur nommé dans le suivi des bugs.
ksmbd : deux failles qui comptent
ksmbd, le serveur SMB intégré au noyau, reçoit deux correctifs de sécurité qui justifient à eux seuls la mise à jour pour les parcs qui l’utilisent.
Le premier : ksmbd ne mettait pas à zéro le padding des lectures composées de type pipe, laissant fuir jusqu’à sept octets de mémoire tas non initialisée. Sept octets, c’est peu — mais c’est de la mémoire de noyau, et une fuite d’information, même minuscule, peut suffire à ébrécher l’ASLR ou à confirmer la présence d’une structure. Le correctif force la remise à zéro de ce padding avant de le renvoyer au client.
Le second est plus sévère : un use-after-free dans le chemin de rupture des oplocks a été corrigé. Les oplocks (opportunistic locks) sont le mécanisme par lequel un serveur SMB délègue la mise en cache à un client pour accélérer les accès ; casser un oplock est une opération de routine, et un use-after-free sur ce chemin ouvre la porte à une exploitation potentielle. Les deux failles touchent le même composant — ksmbd — qui n’est actif que sur les machines qui exposent des partages SMB : c’est précisément le profil des petits serveurs de fichiers self-hosted.
Le reste : mémoire, BPF et DAMON
Derrière ces deux têtes d’affiche, le cycle ratisse large dans la gestion mémoire. Le rollback du vmemmap HugeTLB écrasait les métadonnées de page de tête lors des tentatives de unmap, et la comptabilité des nœuds xarray était imputée au mauvais cgroup de mémoire pendant les fractionnements de page cache. Ce sont des bugs discrets, mais de ceux qui corrompent silencieusement la facturation des cgroups ou l’état des pages — exactement le genre de défaut qui se manifeste par une OOM-kill inexplicable trois mois plus tard.
BPF reçoit un correctif de désactivation de préemption destiné à empêcher une corruption de tampon dans les recherches d’identifiants de pile. DAMON, le sous-système de surveillance de l’accès aux données, voit arriver une série de correctifs de conditions de course et de boucles infinies signés SJ Park. De la maintenance calme, sans exploit public — mais c’est elle qui maintient les serveurs en vie.
L’IA, de l’expérience à la routine
Le fait le plus structurant de ce cycle n’est pas un bug. Plusieurs commits créditent explicitement une assistance IA : un correctif du pilote d’alimentation ab8500_fg remercie « Assisted-by: Codex:gpt-5.6 » pour avoir repéré un use-after-free, et un correctif nouveau remercie Claude. Le même motif était déjà apparu dans la release stable de juin, dans l’arbre DRM.
Il faut lire ce signal pour ce qu’il est. On ne parle plus d’un mainteneur qui expérimente : l’assistance IA devient une ligne de crédit standard dans les correctifs stables. Le bénéfice est réel — un use-after-free de plus attrapé avant qu’il n’atteigne une distribution. Le risque l’est aussi : un correctif généré ou suggéré par une IA passe par la même revue humaine qu’un autre, et le crédit explicite sert précisément à rendre cette chaîne lisible. C’est la bonne pratique, généralisée.
Ce que cela change pour les distributions
Le numéro de version que vous voyez ne dit pas tout. Une distribution LTS ou d’entreprise — Red Hat, Ubuntu LTS, Debian — ne passe presque jamais d’un noyau à l’autre au fil des versions stables : elle backporte les correctifs utiles dans son propre noyau. Concrètement, les deux correctifs ksmbd de ce cycle ont de bonnes chances d’être backportés rapidement, parce qu’ils sont de nature sécurité, tandis que le rattrapage Blackwell attendra la prochaine mise à niveau majeure du noyau de la distribution.
Les distributions rolling — Arch, openSUSE Tumbleweed, les dérivées de Fedora Rawhide — intègrent au contraire 7.2.5 presque immédiatement. Si vous êtes sur une distribution de ce type, uname -r affichera la nouvelle version après votre prochaine mise à jour système ; si vous êtes sur une distribution à noyau fixe, vérifiez plutôt l’avis de sécurité de l’éditeur, qui mentionnera les correctifs ksmbd par leur identifiant de commit plutôt que par un numéro de version. C’est la distinction qui évite de croire qu’une machine est « à jour » parce qu’elle porte un noyau récent — ou l’inverse.
Verdict
Si vous exposez des partages SMB via ksmbd, mettez à jour vers 7.2.5 ou 6.18.51 sans attendre le prochain cycle : la fuite mémoire et le use-after-free touchent un composant réseau, et ce sont les seuls correctifs de ce lot qui méritent un caractère d’urgence. Si vous faites tourner une carte Blackwell avec le pilote libre, ce cycle répare votre sortie vidéo — passez par la mise à jour de votre distribution plutôt que par un backport manuel. Pour tout le reste, appliquez le rythme de mise à jour habituel : la maintenance mémoire, BPF et DAMON est du type « à intégrer proprement », pas « à déployer en urgence ». Et retenez le signal de fond : le noyau stable est désormais entretenu, pour partie, par des correctifs assistés par l’IA — une chaîne à surveiller, pas à craindre.