Failles RCE de Linux KSMBD : analyse de l’exposition par Cyber Kendra

Les listes de diffusion publiques du noyau sont l’endroit où le travail sur Linux se fait. Elles ont moins de charme quand des détails non corrigés d’exécution de code à distance s’y promènent avec un badge visiteur en demandant qui possède l’exposition SMB. Les divulgations concernant KSMBD sont sérieuses, mais la leçon la plus utile est opérationnelle : les équipes ne peuvent pas réduire le risque lié à un service dont elles ignorent qu’il est en cours d’exécution. Quelque part, une feuille de calcul d’inventaire des actifs vient de sentir un courant d’air froid.

Ce que Threat Landscape dit avoir réellement été rendu public

Selon Threat Landscape Blog, la Zero Day Initiative de Trend Micro a divulgué deux problèmes critiques d’exécution de code à distance dans le serveur SMB KSMBD du noyau Linux sur des listes de diffusion publiques du noyau les 21 et 22 octobre 2026. Les problèmes sont suivis sous les références ZDI-CAN-33774 et ZDI-CAN-33549, et Threat Landscape Blog a rapporté que tous deux portent des scores CVSS de 9,0. Ce score n’est pas un film d’horreur, mais il a tendance à entrer dans la pièce avec un éclairage dramatique et une réunion de remédiation très précise dans son sillage.

Threat Landscape Blog a également rapporté qu’au 22 octobre 2026, aucun des deux problèmes ne disposait d’un correctif dans le noyau principal et qu’aucun identifiant CVE n’avait été attribué. La même source a indiqué que le projet du noyau n’attribue des CVE qu’après l’existence d’un correctif dans l’arbre stable, ce qui est le genre de détail de processus qui compte lorsque des dirigeants demandent pourquoi il n’y a pas de joli numéro CVE à coller dans le ticket. La gestion des vulnérabilités adore les identifiants. La réalité arrive parfois avant que l’imprimante à étiquettes ne chauffe.

Pourquoi Cybersecurity News dit que ce n’est pas une histoire de Samba

Cybersecurity News décrit KSMBD comme un serveur de fichiers SMB optionnel intégré au noyau Linux, séparé de Samba. Cette distinction est importante, car de nombreuses organisations savent où Samba est installé, documenté et entretenu à contrecœur, tandis que la configuration du noyau vit souvent dans un autre tiroir mental. Si votre inventaire SMB se limite à Samba, vous regardez peut-être la mauvaise tuyauterie pendant que le plafond fuit.

Threat Landscape Blog ajoute la clause rassurante importante : KSMBD n’est pas activé par défaut sur les grandes distributions comme Red Hat Enterprise Linux. Il peut toutefois être chargé comme module ou intégré dans des noyaux personnalisés, selon la même source. Traduction : ce n’est pas une raison de paniquer devant chaque hôte Linux, mais c’est une très bonne raison de demander si des appliances, des systèmes de stockage, des builds embarqués, des noyaux de laboratoire ou des images personnalisées s’appuient discrètement sur SMB dans le noyau.

Ce que Threat Landscape dit de l’exposition

Threat Landscape Blog a rapporté que ZDI-CAN-33774 ne nécessite aucune authentification et affecte les serveurs exécutant KSMBD sur le port 445. C’est le type de schéma d’exposition que les défenseurs n’aiment pas, car il réduit l’arc narratif de l’acteur malveillant à un court monologue : trouver un service accessible, envoyer du trafic, espérer que le bogue se comporte comme prévu. Le contrôle pratique n’a rien de glamour, ce qui est souvent le signe qu’il pourrait fonctionner : savoir où le port 445 est accessible et le limiter aux réseaux qui en ont réellement besoin.

La seconde faille, ZDI-CAN-33549, a une forme plus étroite. Threat Landscape Blog a indiqué que son exploitation nécessite une interface réseau compatible RDMA, matérielle ou via le pilote logiciel rxe, ainsi qu’un partage KSMBD accessible en écriture et une négociation SMB Direct. Cybersecurity News a également rapporté que le problème implique SMB Direct, qui utilise le réseau RDMA, si bien que l’exposition dépend de la configuration et de l’utilisation ou non de cette fonctionnalité. Autrement dit, le rayon d’impact ne couvre pas toutes les machines Linux, mais les machines concernées sont précisément celles qui méritent une vérification attentive, ennuyeuse et magnifique.

Ce que Cybersecurity News dit que la divulgation enseigne

Cybersecurity News a rapporté que le mainteneur du noyau Linux Greg Kroah-Hartman s’est demandé pourquoi certaines soumissions avaient été envoyées à la liste publique sans correctifs. Le média a également indiqué que ZDI n’avait pas expliqué publiquement ce routage au 23 octobre 2026, de sorte qu’il n’était pas clair s’il s’agissait d’une simple erreur. Cette incertitude n’est pas du carburant à ragots. C’est un rappel que les flux de divulgation font partie de la frontière de sécurité, et que parfois cette frontière a une invitation de calendrier mais pas de garde-fou.

Pour les défenseurs, le calendrier de divulgation est la partie inconfortable. Lorsque des détails techniques arrivent avant un correctif dans le noyau principal, le travail passe de la gestion des correctifs à la gestion de l’exposition. Cela signifie vérifier si KSMBD est présent, s’il est actif, si le port 445 est accessible, si des partages accessibles en écriture existent, et si des chemins SMB Direct ou RDMA sont disponibles. Rien de tout cela n’est cinématographique, mais expliquer après coup que personne ne savait que le noyau servait des fichiers ne l’est pas non plus.

Ce que cela signifie vraiment pour vous

D’après les informations de Threat Landscape Blog et de Cybersecurity News, la première action est l’inventaire, pas la panique. Confirmez si des systèmes Linux exécutent KSMBD, surtout là où existent des noyaux personnalisés, des modules, des charges de travail de stockage ou des déploiements de type appliance. Réduisez ensuite l’accessibilité autour du port 445, examinez les partages KSMBD accessibles en écriture et portez une attention particulière aux environnements utilisant SMB Direct ou RDMA. Continuez à surveiller les correctifs dans le noyau principal et l’attribution des CVE, car l’histoire des correctifs reste la partie que tout le monde veut lire en dernier, mais doit suivre en premier.

La leçon tournée vers l’avenir dépasse ces deux découvertes. La surface d’attaque du noyau continue de s’étendre parce que des fonctionnalités utiles se rapprochent toujours plus du cœur, et chaque commodité devient le futur compte rendu d’incident de quelqu’un si personne n’en est responsable. Traitez KSMBD comme une étude de cas : sachez quels protocoles sont exposés, sachez quelle implémentation les fournit, et ayez un plan de contrôles compensatoires pour les heures délicates entre la divulgation publique et la disponibilité des correctifs. La sécurité ne consiste pas à ne jamais être surpris. Elle consiste à être surpris avec une carte.