Faille Linux KSMBD avant authentification : RCE notée CVSS 9.0 par ZDI, aucun correctif publié à ce jour (ZDI-CAN-33774)

En bref

• ZDI-CAN-33774 : une situation de concurrence avant authentification dans la sélection des gestionnaires de protocole de KSMBD, déclenchée par une seule écriture TCP qui enchaîne une rafale de paquets SMB1 avant un paquet SMB2.
• ZDI-CAN-33549 : un sous-dépassement d’entier dans le chemin SMB Direct (RDMA) de KSMBD.
• Tout hôte exécutant KSMBD dont le port TCP 445 est accessible à des pairs non fiables est exposé. ZDI-CAN-33774 ne nécessite aucune authentification. ZDI-CAN-33549 nécessite en plus la négociation du transport SMB Direct, une interface compatible RDMA et un partage accessible en écriture.
• Le code de preuve de concept public, publié avec les signalements sur les listes publiques du noyau, démontre une fuite de 28 octets de mémoire du tas du noyau par tentative avant authentification et un plantage du noyau, pas une exécution de code. ZDI classe les deux failles comme permettant une exécution de code à distance et décrit un chemin d’écriture pour ZDI-CAN-33774, mais aucune démonstration publique n’aboutit à une exécution de code. Aucune exploitation réelle n’a été signalée au 24 octobre 2026 (Sysdig).
• Aucun correctif n’est encore disponible à l’installation. Celui de ZDI-CAN-33774 a été intégré à l’arbre de développement principal le 20 octobre 2026, mais aucun noyau publié ne le contient. ZDI-CAN-33549 dispose d’une proposition de correctif, sans version corrigée publiée confirmée, et aucune des deux failles n’a d’identifiant CVE. Cessez d’exposer KSMBD : désactivez le service lorsqu’il n’est pas nécessaire, gardez le port 445 hors des réseaux non fiables et laissez SMB Direct désactivé sauf si vous en avez besoin.

La Zero Day Initiative de Trend Micro attribue un score CVSS de 9.0 aux deux failles et crédite Hyeontae Lee pour chacune.

Suis-je concerné ?

ZDI-CAN-33774 vous expose à la fuite et au plantage démontrés si les deux premières conditions sont réunies ; ZDI-CAN-33549 exige en plus la troisième :

• Votre noyau inclut KSMBD et le service est en cours d’exécution. systemctl status ksmbd indique l’état du service ; lsmod | grep ksmbd indique si le module noyau est chargé. Le chargement du module ne suffit pas à établir l’exposition : utilisez la commande ss ci-dessous pour vérifier l’écoute sur le port 445 et confirmer que KSMBD la fournit.
• Le port TCP 445 est accessible depuis Internet, les réseaux de tenants ou tout autre pair auquel vous ne faites pas entièrement confiance.
• Pour ZDI-CAN-33549 uniquement : la connexion peut négocier SMB Direct via une interface compatible RDMA, matérielle ou fournie par le pilote logiciel rxe, et un partage KSMBD accessible en écriture existe.

Les deux failles diffèrent par leurs prérequis et leur état de correction :

Vérifiez ce que vous exécutez :

systemctl status ksmbd          # is the KSMBD service running?
lsmod | grep ksmbd              # is the module loaded?
ss -tlnp | grep :445            # is the SMB port listening, and on which address?

Où KSMBD s’exécute réellement :

Comment corriger le problème ?

Aucun correctif publié n’est disponible à l’installation pour l’une ou l’autre faille. Il faut donc supprimer l’exposition plutôt qu’appliquer un patch :

1. Arrêtez et désactivez KSMBD là où vous n’avez pas besoin de servir SMB depuis l’espace noyau : systemctl stop ksmbd && systemctl disable ksmbd. Compromis : cela supprime entièrement le service de fichiers.
2. Là où le service doit rester actif, limitez le port 445 aux réseaux dont vous jugez les hôtes fiables, sur le pare-feu de l’hôte et tout pare-feu périmétrique. Compromis : le service reste disponible, mais seuls des pairs fiables peuvent atteindre les deux failles. Tout chemin permettant un accès non fiable laisse ZDI-CAN-33774 exploitable, car cette faille ne nécessite aucune authentification.
3. Laissez SMB Direct et RDMA désactivés sauf si vous les utilisez spécifiquement, ce qui ferme ZDI-CAN-33549. Compromis : cette mesure ne traite pas ZDI-CAN-33774, la faille avant authentification.

Surveillez la publication de noyaux corrigés plutôt que de deviner les dates. Les correctifs intégrés à l’arbre principal mettent généralement plusieurs semaines à atteindre les branches stables, puis les noyaux des distributions. Le projet noyau n’attribue des identifiants CVE qu’après la disponibilité d’un correctif dans un arbre stable. Lorsque votre distribution livre un noyau contenant le commit 68f410faedaf (« ksmbd: wait for negotiation before receiving another PDU »), ZDI-CAN-33774 est corrigée sur cet hôte. Pour ZDI-CAN-33549, demandez à votre fournisseur si son noyau inclut le correctif du 23 octobre, « smb: smbdirect: fix buffer length underflow in RDMA transfers ».

Quelle est la cause racine ?

Le thread de réception KSMBD pouvait lire l’unité de données de protocole suivante avant la fin du worker de négociation. Une requête SMB2 enchaînée pouvait donc remplacer la table des gestionnaires de la connexion pendant qu’un worker traitait encore une requête SMB1 antérieure et plus courte.

Le commit de correction du mainteneur, 68f410faedaf, décrit précisément le mécanisme :

Le thread de réception met une requête en file d’attente et peut lire la PDU suivante avant que le worker de négociation ait terminé. Tant que need_neg est défini, la PDU suivante peut amener ksmbd_init_smb_server() à remplacer conn->ops. Une requête SMB2 enchaînée peut ainsi faire traiter au worker une requête SMB1 antérieure et plus courte avec les opérations SMB2, et le faire lire au-delà de son tampon.

Une négociation multiprotocole SMB1 peut être suivie d’un SMB2 NEGOTIATE qui modifie de nouveau conn->ops.

Le mécanisme, étape par étape :

• conn->ops est la table des gestionnaires de la connexion : l’ensemble des pointeurs de fonction qui transforment une commande SMB décodée en action. SMB1 et SMB2 ont des structures de commande différentes. Le serveur attribue donc l’une ou l’autre table pendant la négociation, lorsque need_neg est défini.
• Cette attribution a lieu dans ksmbd_init_smb_server(). Réexécuter cette fonction au milieu d’une connexion remplace conn->ops alors que du travail mis en file sous l’ancienne table peut encore être en cours.
• Une requête enchaînée, plusieurs unités de données de protocole regroupées dans une seule écriture TCP, force ce chevauchement : le thread de réception lit le paquet SMB2 et relance la négociation avant que le worker mis en file pour le paquet SMB1 antérieur et plus court ait terminé.
• Le worker applique alors la logique des gestionnaires SMB2 à un tampon dimensionné pour SMB1 et lit au-delà de sa fin.

Pour ZDI-CAN-33549, le signalement décrit un sous-dépassement d’entier dans le chemin SMB Direct : un client fournit des descripteurs de tampons RDMA dont le premier est plus long que le payload déclaré. Cela provoque un débordement du compteur de taille du serveur, puis une copie mémoire ultérieure dépasse la fin d’un tampon alloué.

Comment la faille est-elle exploitée ?

Aucune exploitation réelle n’a été signalée, et le chemin d’attaque figure dans les signalements eux-mêmes, publiés sur les listes de diffusion publiques du noyau avec le code source des preuves de concept :

1. L’attaquant se connecte au port 445 d’un hôte exécutant KSMBD. Pour ZDI-CAN-33774, aucune authentification n’est nécessaire : c’est pourquoi tout serveur exécutant KSMBD sur ce port est exposé.
2. L’attaquant envoie une seule écriture TCP contenant une rafale de paquets SMB1 courts suivis d’un paquet SMB2.
3. Le thread de réception met le traitement des paquets SMB1 en file et lit le paquet SMB2, ce qui relance la négociation et remplace conn->ops par la table des gestionnaires SMB2.
4. Le worker en attente traite la requête SMB1 antérieure et plus courte avec les opérations SMB2, puis lit au-delà de la fin du tampon plus court.
5. La preuve de concept publique démontre une fuite de 28 octets de mémoire du tas du noyau par tentative, avant authentification, ainsi qu’un plantage du noyau. Le signalement de ZDI décrit également un chemin permettant d’écrire au-delà du tampon une fois que l’attaquant a accès à un partage, mais aucune démonstration publique n’aboutit à une exécution de code, selon Sysdig.

Pour ZDI-CAN-33549, l’attaquant est un client qui négocie SMB Direct et fournit des descripteurs de tampons RDMA spécialement conçus. Il lui faut une interface serveur compatible RDMA, un partage accessible en écriture et le transport SMB Direct. Cette faille nécessite donc davantage de conditions que ZDI-CAN-33774.

Quel est le déroulement de l’attaque ?

L’attaque entière tient dans une écriture TCP enchaînée qui fait changer au serveur sa table de gestionnaires pendant qu’un worker attend son traitement.

La synchronisation manquante se situe en C : rien n’oblige le thread de réception à attendre le worker de négociation avant de lire l’unité de données de protocole suivante.

Que peut faire un attaquant ?

Contre un hôte exposé, l’impact démontré publiquement est une divulgation de mémoire du noyau, 28 octets du tas par tentative avant authentification, et un plantage du noyau, qui constitue un déni de service pour un serveur de fichiers. ZDI attribue aux deux failles un score CVSS de 9.0 en les classant comme exécution de code à distance. Son signalement ZDI-CAN-33774 décrit un chemin d’écriture au-delà du tampon après obtention d’un accès à un partage : une corruption mémoire au-delà de la fuite démontrée est donc plausible. Aucune démonstration publique ne la transforme en exécution de code, et aucune utilisation réelle n’a été signalée.

Conditions nécessaires à chaque faille :

• ZDI-CAN-33774 : pour déclencher la fuite et le plantage, un noyau compilé avec KSMBD, le service actif et le port 445 accessible ; aucun compte ni partage n’est nécessaire. Le chemin d’écriture décrit par ZDI nécessite en plus un accès à un partage.
• ZDI-CAN-33549 : toutes les conditions précédentes, avec en plus SMB Direct négocié, une interface compatible RDMA (matérielle ou via le pilote logiciel rxe) et un partage accessible en écriture.
• Aucune des deux failles n’affecte Samba en espace utilisateur (smbd), dont le code est distinct et ne partage pas le chemin de sélection des gestionnaires de KSMBD dans le noyau.

Pourquoi le correctif fonctionne-t-il ?

Le correctif de ZDI-CAN-33774, commit 68f410faedaf du mainteneur KSMBD Namjae Jeon, ajoute une attente dans le chemin de réception de fs/smb/server/server.c :

--- a/fs/smb/server/server.c
+++ b/fs/smb/server/server.c
@@ static int queue_ksmbd_work(struct ksmbd_conn *conn)
    struct ksmbd_work *work;
+   bool wait_for_neg = ksmbd_conn_new(conn) || ksmbd_conn_need_negotiate(conn);
    int err;
@@
    INIT_WORK(&work->work, handle_ksmbd_work);
    ksmbd_queue_work(work);
+   /* Negotiation can change conn->ops, finish it before reading another PDU. */
+   if (wait_for_neg)
+       wait_event(conn->req_running_q,
+              atomic_read(&conn->req_running) == 0);
    return 0;

Après avoir mis du travail en file sur une connexion nouvelle ou encore en cours de négociation, le thread de réception attend désormais sur conn->req_running_q que toutes les requêtes en attente soient terminées. La table des gestionnaires ne peut plus être remplacée pendant qu’un worker traite une requête antérieure ; des données SMB1 ne peuvent donc plus être traitées avec des opérations SMB2. Le commit conserve la sémantique de need_neg. Son message présente le changement comme le maintien d’opérations stables pendant les deux étapes de la négociation.

Le correctif résout entièrement cette situation de concurrence et répond à un signalement antérieur lié, en créditant ihopenre-eng. Deux limites demeurent : il se trouve dans l’arbre de développement principal, où il a été intégré le 20 octobre 2026, donc aucun noyau publié ne le contient encore ; et il ne touche pas au chemin SMB Direct, si bien que ZDI-CAN-33549 exige son correctif SMB Direct distinct.

Comment vérifier si j’ai été compromis ?

Aucune exploitation n’a été signalée et aucun indicateur de compromission n’a été publié pour ces deux failles. Si vous exécutez KSMBD en l’exposant à des réseaux non fiables et souhaitez auditer :

• Examinez les journaux de connexion au port 445 et du pare-feu pour repérer des adresses source inattendues. Si des captures réseau sont disponibles, recherchez des rafales de requêtes suivies de déconnexions brusques ; ce motif seul ne prouve pas une exploitation.
• Vérifiez les journaux du noyau pour des traces d’oops ou de panic mentionnant ksmbd ou fs/smb/server, puisque la preuve de concept publique peut faire planter le noyau.
• Traitez la fuite de 28 octets du tas par tentative comme une exposition réelle : chaque tentative divulgue du contenu du tas du noyau. Des tentatives répétées contre un hôte exposé peuvent donc avoir collecté de la mémoire même sans plantage. Si vous soupçonnez une compromission, appliquez la réponse habituelle à un incident présumé au niveau du noyau : isolez l’hôte, renouvelez tous ses identifiants et reconstruisez-le à partir d’une image réputée saine.

Chronologie

• 2026-09-30 : le mainteneur KSMBD Namjae Jeon rédige le commit de correction 68f410faedaf, « ksmbd: wait for negotiation before receiving another PDU », en créditant ihopenre-eng, en réponse à un signalement antérieur.
• 2026-10-20 : le commit est intégré à l’arbre de développement principal Linux (horodatage du committer : 20 octobre à 23:55 UTC).
• 2026-10-21 : ZDI divulgue ZDI-CAN-33774 et ZDI-CAN-33549, chacune notée CVSS 9.0 et attribuée à Hyeontae Lee, sur les listes publiques du noyau sans correctif joint (horodatages UTC).
• 2026-10-21 : le mainteneur SMB Direct Stefan Metzmacher demande au chercheur de tester la branche de développement for-7.5/smbdirect comme correctif possible pour ZDI-CAN-33549.
• 2026-10-22 : le mainteneur KSMBD Namjae Jeon répond que le commit 68f410faedaf corrige déjà la situation de concurrence.
• 2026-10-22 : le mainteneur du noyau stable Greg Kroah-Hartman répond en demandant des correctifs plutôt que des divulgations publiques.
• 2026-10-22 : The Hacker News couvre les divulgations.
• 2026-10-23 : Namjae Jeon publie un correctif plus limité du sous-dépassement SMB Direct après que Stefan Metzmacher a recommandé une correction minimale.
• 2026-10-23 à 25 : AlmaLinux, CloudLinux et Sysdig publient des analyses ; la preuve de concept publique est documentée comme une fuite de 28 octets du tas du noyau par tentative avant authentification, avec plantage, et non comme une exécution de code.
• 2026-10-26 : publication de cet article. Aucune exploitation réelle n’a été signalée et aucune des deux failles ne figure dans le catalogue CISA KEV.

FAQ

Pourquoi ces failles n’ont-elles pas d’identifiant CVE ?

Le projet noyau Linux n’attribue des numéros CVE qu’après la disponibilité d’un correctif dans un noyau stable publié, selon sa politique CVE. Les deux failles ont été divulguées sur les listes publiques avant qu’un noyau publié contienne un correctif : elles sont donc suivies sous leurs identifiants ZDI-CAN. Les identifiants CVE devraient apparaître lorsque les noyaux stables intégreront les correctifs.

La preuve de concept publique donne-t-elle aux attaquants une exécution de code à distance ?

Non. Elle démontre une fuite de 28 octets de mémoire du tas du noyau par tentative avant authentification et un plantage du noyau. Les évaluations CVSS 9.0 de ZDI traitent les failles comme une exécution de code à distance, et son signalement ZDI-CAN-33774 décrit un chemin d’écriture au-delà du tampon après obtention d’un accès à un partage, mais aucune démonstration publique ne montre une exécution de code, selon Sysdig.

Le noyau de ma distribution est-il affecté ?

Seulement si la distribution compile KSMBD et si le service a été démarré. Red Hat Enterprise Linux n’inclut pas KSMBD par défaut, les noyaux AlmaLinux et CloudLinux 9 et 10 ne le compilent pas, et Debian et Ubuntu ne l’exécutent qu’après l’installation de ksmbd-tools et le démarrage du service. Les hôtes à auditer sont les NAS et les serveurs de stockage livrant des noyaux avec KSMBD activé pour servir les fichiers.

Les serveurs Samba sont-ils affectés ?

Non. Le smbd de Samba en espace utilisateur est une implémentation distincte qui ne partage pas le code de sélection des gestionnaires de KSMBD dans le noyau. Le logiciel exposé est KSMBD, le serveur SMB intégré au noyau, identifiable avec systemctl status ksmbd ou lsmod | grep ksmbd.

Quand un correctif arrivera-t-il dans mon noyau ?

Le correctif ZDI-CAN-33774 a atteint l’arbre de développement principal le 20 octobre 2026. Les correctifs de cet arbre mettent généralement plusieurs semaines à atteindre les branches stables, puis les noyaux des distributions. Pour ZDI-CAN-33549, Stefan Metzmacher a d’abord demandé au chercheur de tester la branche de développement for-7.5/smbdirect. Namjae Jeon a ensuite publié un correctif plus limité le 23 octobre ; cela ne prouve pas sa disponibilité dans le noyau publié de votre distribution. Suivez les bulletins noyau de votre distribution pour le commit 68f410faedaf (ZDI-CAN-33774) et le correctif SMB Direct du 23 octobre (ZDI-CAN-33549), et confirmez séparément la couverture de chacun.

Dois-je utiliser SMB Direct pour être concerné par les deux failles ?

Non. ZDI-CAN-33549 nécessite SMB Direct, une interface compatible RDMA et un partage accessible en écriture. ZDI-CAN-33774 n’a besoin d’aucun de ces éléments : tout pair non authentifié pouvant atteindre le port 445 d’un hôte exécutant KSMBD peut l’atteindre. C’est donc son exposition qu’il faut supprimer en priorité.

Repérez les serveurs SMB exposés avant un attaquant

Suivez le guide de scan réseau d’Ostorlab : sélectionnez New Scan → Network, saisissez vos adresses ou plages IP, choisissez Full Network Scan et lancez le scan. Examinez les résultats concernant le port 445, puis confirmez localement si le service est KSMBD ou Samba en espace utilisateur. Restreignez l’accès aux services KSMBD exposés en attendant un noyau de distribution corrigé.

Références

• Signalement principal ZDI-CAN-33774, repris par Openwall, avec l’horodatage de divulgation du 21 octobre UTC et le chemin d’écriture décrit : https://lists.openwall.net/linux-kernel/2026/10/21/2694
• Discussion de Stefan Metzmacher sur la branche SMB Direct et un correctif minimal, 23 octobre : https://lists.openwall.net/linux-kernel/2026/10/23/739
• Correctif du sous-dépassement SMB Direct joint par Namjae Jeon, 23 octobre : https://lists.openwall.net/linux-kernel/2026/10/23/971
• The Hacker News, « Two CVSS 9.0 Linux KSMBD RCE Flaws Disclosed on Public Mailing Lists Before Kernel Fixes », 22 octobre 2026, mis à jour le 26 octobre, avec les mécanismes des failles, les réponses des mainteneurs, la portée de la preuve de concept et la situation des distributions : https://thehackernews.com/2026/10/two-cvss-90-linux-ksmbd-rce-flaws.html (consulté le 26 octobre 2026)
• Bulletins ZDI à venir, répertoriant ZDI-CAN-33774 et ZDI-CAN-33549 avec CVSS 9.0, éditeur Linux, découverts par Hyeontae Lee : https://www.zerodayinitiative.com/advisories/upcoming/ (consultés le 26 octobre 2026)
• Signalement ZDI de ZDI-CAN-33774 sur les listes publiques du noyau : https://lore.kernel.org/lkml/BYAPR01MB383076AC412E19C48CFBEAE980662@BYAPR01MB3830.prod.exchangelabs.com/ (signalement principal)
• Signalement ZDI de ZDI-CAN-33549 sur les listes publiques du noyau : https://lore.kernel.org/lkml/BYAPR01MB3830472B5702C089B0BBB77D80662@BYAPR01MB3830.prod.exchangelabs.com/ (signalement principal)
• Commit de correction 68f410faedaf, « ksmbd: wait for negotiation before receiving another PDU », dans l’arbre Linux principal, rédigé le 30 septembre 2026, horodatage du committer le 20 octobre 2026 : https://github.com/torvalds/linux/commit/68f410faedaf6ee74d81e574733c50ebcc1bd8ed (consulté le 26 octobre 2026)
• Sysdig sur les six signalements noyau d’octobre, la portée de la preuve de concept et l’état non intégré du correctif : https://www.sysdig.com/blog/detecting-and-mitigating-zdi-can-33367-and-five-other-linux-flaws (référencé via The Hacker News, 26 octobre 2026)
• AlmaLinux sur les signalements publics des listes du noyau : https://almalinux.org/blog/2026-10-23-zdi-can-33367/ (référencé via The Hacker News, 26 octobre 2026)
• CloudLinux sur la preuve de concept KSMBD et la compilation par distribution : https://blog.cloudlinux.com/zdi-can-33367 (référencé via The Hacker News, 26 octobre 2026)
• Document de solution Red Hat 6991749, KSMBD non inclus par défaut dans RHEL : https://access.redhat.com/solutions/6991749 (référencé via The Hacker News, 26 octobre 2026)
• Politique d’attribution des CVE du noyau Linux, émises uniquement après un correctif dans l’arbre stable : https://docs.kernel.org/process/cve.html (référencée via The Hacker News, 26 octobre 2026)