Deux failles RCE cotées CVSS 9.0 dans KSMBD rendues publiques avant tout correctif du noyau Linux
Le 22 octobre 2026, deux failles d’exécution de code à distance cotées CVSS 9.0 dans KSMBD, le serveur SMB intégré au noyau Linux, circulent publiquement sans correctif dans le noyau principal. L’une est exploitable sans authentification sur le port 445 : vérifiez immédiatement si le module est chargé sur vos serveurs.
22 octobre 2026. Deux failles d’exécution de code à distance cotées CVSS 9.0 par la Zero Day Initiative de Trend Micro touchent KSMBD, le serveur SMB intégré au noyau Linux. 22 octobre 2026. Aucun correctif n’existe encore dans le noyau principal ni dans linux-next. 22 octobre 2026. L’une des deux failles se déclenche avant toute authentification réseau, sur le port 445. Pourquoi c’est important : des bugs de noyau découverts par des outils d’IA sont désormais jetés sur des listes publiques sans correctif — et les défenseurs doivent apprendre à vivre avec des fenêtres de divulgation qui ne protègent plus personne.
Deux failles, dont une exploitable sans authentification
Les deux failles sont référencées par la ZDI sous les identifiants ZDI-CAN-33774 et ZDI-CAN-33549. La plus grave, ZDI-CAN-33774, n’exige aucune authentification : elle expose tout serveur qui fait tourner KSMBD sur le port 445.
Le défaut est une course dans l’affectation de la table de gestionnaires de KSMBD. Une rafale de courts paquets SMB1 suivie d’un paquet SMB2 dans le même envoi TCP amène les workers à traiter des données SMB1 avec un gestionnaire SMB2, lisant au-delà de la fin du tampon plus court. Un chemin d’écriture au-delà du tampon existe aussi une fois qu’un attaquant a accès à un partage. La seconde, ZDI-CAN-33549, est un dépassement d’entier (integer underflow) dans le chemin SMB Direct : un client fournit des descripteurs de tampon RDMA dont le premier est plus long que la charge déclarée, ce qui fait boucler le compteur de taille du serveur et permet à une copie mémoire de déborder d’un tampon alloué. Elle exige trois conditions : une interface RDMA (matérielle ou via le pilote logiciel rxe), un partage KSMBD accessible en écriture, et un client négociant SMB Direct.
Ni l’une ni l’autre n’a de correctif nommé dans le noyau principal à la date du 22 octobre. Phoronix indique que Stefan Metzmacher, mainteneur de SMB Direct, a soumis un correctif pour ZDI-CAN-33549 visant le prochain cycle de développement, mais cela n’est pas confirmé ailleurs. Et aucune des deux failles n’a encore d’identifiant CVE : le projet noyau n’en attribue qu’une fois qu’un correctif existe dans un arbre stable. C’est la première pièce du problème — une vulnérabilité publique sans CVE ni correctif est difficile à suivre dans un inventaire qui indexe tout par CVE.
La divulgation a précédé le correctif, et c’est un choix
L’affaire ne se réduit pas à deux bugs : elle révèle une tension dans la manière dont les failles découvertes par l’IA entrent dans le processus de divulgation du noyau. Les rapports de la ZDI créditent TrendAI, le scanner d’IA de Trend Micro, comme découvreur. Or la documentation de sécurité du noyau Linux, mise à jour en mai 2026 à la suite des consignes de Linus Torvalds, stipule que les bugs trouvés par des outils d’IA sont, par définition, déjà publics et doivent être envoyés aux listes de développement des sous-systèmes.
La ZDI a suivi cette logique : elle a copié des listes publiques aux côtés de l’adresse privée de sécurité du noyau, sans joindre de correctif à aucun des rapports. Greg Kroah-Hartman, mainteneur des branches stables, a répondu à trois des cinq rapports noyau en quelques minutes. Au rapport sur le pilote GPU VMware : « Pour une raison quelconque, vous avez envoyé ceci à des listes publiques sans joindre de correctif, donc nous ne pouvons pas faire grand-chose. » Sur le rapport du pilote NVMe, dix-sept secondes plus tard : « Encore une fois, pas de correctif, et envoyé à une liste publique ? Corrigez votre processus de soumission. »
La conséquence est concrète pour quiconque exploite KSMBD : deux RCE cotées 9.0 sont publiques, aucune n’a de correctif, et la remontée vers les branches stables puis les noyaux de distribution prendra « des semaines » une fois le correctif écrit. Entre-temps, la seule protection est de réduire la surface d’exposition.
Ce que vous devez vérifier maintenant
Deux commandes suffisent pour savoir si vous êtes exposé. systemctl status ksmbd confirme si le service est actif, et lsmod | grep ksmbd si le module est chargé. Red Hat Enterprise Linux n’embarque pas KSMBD par défaut, d’après la documentation de support de Red Hat — mais les distributions qui l’activent, souvent pour exposer des partages SMB légers sans Samba, le font précisément sur le port 445 que vise ZDI-CAN-33774.
Le périmètre exact est utile à connaître. ZDI-CAN-33774 n’exige aucune authentification, mais son chemin d’écriture au-delà du tampon suppose un accès à un partage ; le chemin de lecture s’arrête à une lecture hors limites. ZDI-CAN-33549 exige SMB Direct, donc une interface RDMA et une négociation spécifique — un sous-ensemble plus rare, mais présent dans les grappes de stockage et les environnements haute performance. Dans tous les cas, si vous n’avez pas besoin de KSMBD, désactivez-le : c’est la seule atténuation immédiate face à une faille sans correctif.
Les cinq rapports noyau de la ZDI ne concernent pas tous SMB. ZDI-CAN-33367, découvert par le chercheur p1r0x, est une élévation de privilèges locale dans la pile réseau ; ZDI-CAN-34068 une élévation locale dans le pilote GPU VMware ; ZDI-CAN-34076 une divulgation d’information dans la cible NVMe ; ZDI-CAN-32005 un débordement de tampon dans ConnMan. Ils partagent le même défaut de procédure : des rapports publics, sans correctif, qui laissent les opérateurs sans levier.
La politique de divulgation des bugs trouvés par l’IA est cassée
Le point de friction est net dans les échanges : la ZDI applique une lecture littérale de la consigne de mai 2026 — un bug trouvé par un outil d’IA est public par définition, donc il va sur les listes publiques — tandis que le noyau attend toujours un correctif avant qu’une faille exploitable devienne publique. Le résultat est le pire des deux mondes : la faille est publique, mais le correctif n’existe pas.
La colère de Greg Kroah-Hartman vise précisément ce déséquilibre. Un rapport envoyé à une liste publique sans correctif ne donne « pas grand-chose » à faire aux mainteneurs : ils apprennent l’existence de la faille en même temps que les attaquants, sans avoir le patch qui permettrait de la corriger avant la ruée. Historiquement, le processus [email protected] existe pour que le correctif soit écrit avant la publication — c’est lui qui a été contourné.
Pour un opérateur, la conséquence est une inversion des rôles. Jusqu’ici, la veille consistait à surveiller les CVE publiées après correctif et à planifier les mises à jour. Avec des failles publiques sans correctif ni CVE, la veille doit remonter d’un cran : suivre les listes publiques, les rapports ZDI et les fils de discussion, et anticiper la mitigation avant que le correctif ne descende. C’est un changement de posture — de la mise à jour planifiée à la défense en configuration — que la communauté n’a pas encore absorbé.
Verdict
Si vous n’utilisez pas KSMBD, désactivez-le immédiatement — systemctl disable --now ksmbd — et fermez le port 445 au pare-feu. C’est la seule atténuation disponible face à une RCE pré-authentification sans correctif. Si vous avez besoin de partages SMB, préférez Samba en espace utilisateur, qui n’est pas affecté par ces défauts du module noyau, ou segmentez strictement l’accès au port 445 en attendant le correctif, puis appliquez-le dès qu’il atteint votre distribution — ces correctifs mettront des semaines à descendre. Si vous suivez la veille noyau, intégrez le fait nouveau : la frontière entre « découverte privée » et « divulgation publique » a changé pour les bugs trouvés par l’IA, et le temps entre publication et correctif, autrefois quasi nul pour les failles sérieuses, est désormais un intervalle ouvert que vous devez couvrir par la configuration. La leçon rejoint celle de nos analyses sur le durcissement du noyau : la mitigation par défaut compte autant que le correctif, parce que le correctif peut arriver trop tard.