Six failles publiées sans correctif sur les listes du noyau Linux : ksmbd en première ligne, mais Samba n’est pas concerné

Les 21 et 22 octobre, selon Next, la Zero Day Initiative (ZDI) de Trend Micro a envoyé six rapports de vulnérabilités qui se sont retrouvés en copie de listes de diffusion publiques du noyau Linux, alors qu’aucun correctif n’était publié. Deux de ces failles, dans le serveur de fichiers ksmbd intégré au noyau (un serveur qui partage des documents sur le réseau), sont qualifiées de critiques. Voici ce que l’on sait à ce jour, et ce qu’il est raisonnable de faire sur ses machines.

Selon Next, les rapports étaient adressés à la liste de sécurité privée du noyau, mais les listes publiques linux-kernel, linux-cifs, netdev et dri-devel figuraient en copie. Les sources ne comptent pas tout à fait pareil : Next parle de six rapports envoyés sur deux jours, tandis que la société Sysdig évoque cinq rapports adressés le 21 octobre à l’équipe de sécurité du noyau, avec les listes publiques en copie à chaque fois. Sysdig précise que les rapports comportaient des détails permettant de les reproduire, et que plusieurs n’avaient ni correctif joint ni correction dans un noyau diffusé.

Six failles, deux critiques

Les six rapports touchent des composants très différents. Deux visent ksmbd, le serveur SMB (le protocole de partage de fichiers de Windows) intégré au noyau, et sont jugées critiques. Une troisième concerne skb_zerocopy, du côté de la pile réseau : TuxCare indique que son exploit a obtenu les droits root sur Debian 12 et 13 et sur Ubuntu 24.04 et 26.04, entre autres. La quatrième vise vmwgfx, le pilote de carte graphique virtuelle de VMware : il s’agit d’une élévation locale de privilèges, c’est-à-dire qu’un utilisateur déjà présent sur la machine peut obtenir des droits supérieurs. La cinquième, dans le pilote nvmet, est une fuite d’informations par mémoire non initialisée, et la sixième un dépassement de pile dans ConnMan, un gestionnaire de réseau.

Pour ksmbd, mieux vaut distinguer plusieurs points. D’abord, ksmbd n’est pas Samba, et il ne fonctionne que si un administrateur l’a installé puis démarré. Next le décrit comme un serveur compatible Samba mais qui n’est pas Samba, et TuxCare explique qu’il ne tourne qu’après l’installation de ksmbd-tools, absent par défaut, et le lancement du service. Ensuite, l’exploitation suppose des conditions : selon Next, une écriture hors limites devient possible à condition que le pirate ait accès à un partage, et le support de SMB Direct est une option, désactivée par défaut.

Côté correctifs, la situation évolue encore. Next écrit qu’il est probable qu'aucun correctif ne sera disponible avant plusieurs semaines. Slashdot, qui relaie Phoronix, signale toutefois qu’il existe un correctif dans une branche de développement destinée à Linux v7.5 pour la faille SMB Direct, ce qui ne signifie pas qu’il ait atteint les noyaux des distributions. TuxCare, de son côté, relève qu’aucun des rapports n’avait de correctif ni de numéro CVE, et que trois comportaient le code complet d’une démonstration.

Accident ou procédure ?

Le développeur Greg Kroah-Hartman a répondu au rapport sur le pilote VMware en reprochant à ses auteurs de l’avoir envoyé dans des listes publiques, sans correctif. TuxCare évoque un envoi par erreur, et Slashdot, qui relaie Phoronix, y voit une erreur apparente. Mais Next rapporte que le caractère accidentel de ces publications est contesté : la cause reste donc incertaine. Nous ne tranchons pas : seuls les faits établis comptent ici.

Cette affaire tombe sur une règle précise de la documentation du noyau. Celle-ci demande à quiconque a recouru à une assistance de l’IA pour repérer un bogue de le traiter comme public, et rappelle que la liste de sécurité n’est pas un canal de divulgation. Selon Next, une vulnérabilité trouvée grâce à l’IA doit être considérée comme publique. La documentation ajoute que la plupart des bogues sont traités publiquement, afin de mobiliser le plus large public possible et de trouver la meilleure solution.

Cette même documentation demande toutefois de ne pas diffuser publiquement un code de reproduction, qui pourrait causer des dommages involontaires. Or Sysdig note que les rapports comportaient des détails de reproduction, et TuxCare que trois incluaient le code complet d’une démonstration. À notre avis, cet écart entre la règle écrite et ce qui a circulé est au cœur du débat : traiter un bogue en public n’implique pas de publier de quoi l’exploiter avant qu’un correctif existe.

Que faire sur ses machines

En attendant les correctifs, Sysdig recommande d’abord de recenser les machines où ksmbd fonctionne. Il conseille ensuite de décharger le module et de le bloquer sur les hôtes qui n’en ont pas besoin, de restreindre le port TCP 445 aux réseaux de confiance là où ksmbd doit rester, et de désactiver SMB Direct, sauf si le réseau de stockage dépend de RDMA. TuxCare précise par ailleurs qu’AlmaLinux et CloudLinux 9 et 10 ne compilent pas ksmbd du tout. Pour le reste, la seule parade durable consiste à installer les mises à jour de sa distribution dès qu’elles paraissent.

Pour une TPE, une PME ou un particulier, le risque concret dépend d’une question simple : un serveur de fichiers ksmbd tourne-t-il quelque part sur le réseau ? Un serveur qui partage ses fichiers avec Samba n’est pas concerné par les deux failles critiques ; celui qui s’appuie sur ksmbd doit être identifié, limité au réseau local, puis mis à jour dès que les correctifs arrivent. Les autres failles, locales ou propres aux invités VMware, demandent surtout de tenir ses machines à jour. Si vous ne savez pas ce que fait tourner votre serveur, nous pouvons vous aider à le vérifier, dans la mesure de nos disponibilités.