Six failles du noyau Linux divulguées par erreur : deux RCE critiques dans KSMBD

Le 21 octobre 2026, la Zero Day Initiative (ZDI) de Trend Micro a publié par erreur six rapports de vulnérabilités non corrigées du noyau Linux sur la mailing list publique LKML (Linux Kernel Mailing List), au lieu de la liste de sécurité privée réservée à ce type de signalements. Parmi ces six failles, deux touchent KSMBD, le serveur SMB intégré au noyau depuis Linux 5.15, avec un score CVSS de 9.0 sur 10 et une exploitation possible à distance sans authentification sur le port TCP 445. Si vous administrez un VPS Linux ou un serveur dédié, voici ce que vous devez vérifier en ligne de commande.

Source : Phoronix, "LKML New Trend Vulnerabilities", 21 octobre 2026. Rapports ZDI confirmés sur lore.kernel.org.

Une divulgation accidentelle sur une liste publique

Les rapports de vulnérabilités du noyau Linux sont normalement envoyés à l'adresse security@kernel.org, une liste privée accessible aux seuls mainteneurs habilités à produire des correctifs avant la divulgation publique. Les six rapports ZDI ont été postés sur la LKML, lisible par quiconque dispose d'un navigateur web. Greg Kroah-Hartman, co-mainteneur principal du noyau Linux, a répondu publiquement : "And again, no patch, and a public list?" (encore une fois, pas de patch, et une liste publique). Trois des six rapports contenaient le code source complet du PoC (proof of concept), ce qui signifie qu'un attaquant peut reproduire l'exploitation sans effort de rétro-ingénierie.

Pour les administrateurs de serveurs Linux, la conséquence pratique est simple : les détails techniques de ces vulnérabilités sont désormais publics, les correctifs ne sont pas encore tous intégrés dans les noyaux stables, et des scripts d'exploitation circulent. Il faut ouvrir un shell sur chaque machine, vérifier si les composants concernés sont actifs et appliquer les mesures de mitigation décrites ci-dessous.

Les deux failles critiques KSMBD (CVSS 9.0)

KSMBD (kernel SMB daemon) est un serveur de partage de fichiers SMB/CIFS intégré directement dans le noyau Linux depuis la version 5.15, sortie en novembre 2021. Contrairement à Samba, qui fonctionne en espace utilisateur (processus smbd), KSMBD s'exécute dans l'espace noyau (kernel space) pour des performances supérieures sur les opérations SMB Direct via RDMA. Comme tout module noyau, une faille dans KSMBD donne à l'attaquant un accès direct à la mémoire RAM du système d'exploitation et au processeur, sans les barrières de sécurité qui isolent les processus en espace utilisateur. Les deux failles critiques suivantes ne concernent que KSMBD, pas Samba.

ZDI-CAN-33549 : integer underflow dans SMB Direct (RCE)

La première faille, référencée ZDI-CAN-33549, est un integer underflow (dépassement d'entier vers le bas) dans le code de gestion des connexions RDMA. Le rapport ZDI décrit un débordement de tas (heap overflow) pouvant atteindre 8 Ko de mémoire RAM noyau. Lorsque le serveur KSMBD traite une requête SMB2 WRITE contenant plusieurs descripteurs de buffers RDMA, le premier descripteur peut forcer la variable de taille du buffer à zéro. La soustraction suivante provoque un underflow : la valeur boucle vers un entier très grand, ce qui permet au second descripteur de contourner les vérifications de limites. Le résultat est une écriture hors limites (out-of-bounds write) sur le tas du noyau, exploitable pour obtenir une exécution de code à distance avec les privilèges du noyau.

• Score CVSS : 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
• Prérequis : CONFIG_SMB_SERVER_SMBDIRECT=y dans la configuration du noyau, un périphérique RDMA accessible et un partage SMB en écriture
• Authentification requise : non
• CVE : aucun identifiant CVE attribué au 24 octobre 2026

ZDI-CAN-33774 : race condition dans le dispatch de protocole (RCE)

La seconde faille, ZDI-CAN-33774, est une race condition (condition de concurrence) dans la gestion des protocoles SMB1 et SMB2 par KSMBD. Le serveur sélectionne les opérations de protocole (conn->ops) au moment de la mise en file d'attente d'une requête, mais les déréférence au moment du traitement par un thread de travail. Un attaquant peut envoyer une requête SMB1 (40 octets) immédiatement suivie d'une requête SMB2, ce qui force le changement de gestionnaire pendant l'exécution. La requête SMB1 est alors traitée avec le gestionnaire SMB2, qui lit au-delà des 40 octets alloués en RAM : fuite de 28 octets de mémoire du tas du noyau (SessionId, Signature, données adjacentes). Un chemin de code secondaire permet également une écriture hors limites.

• Score CVSS : 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
• Prérequis : KSMBD activé avec un partage guest accessible sur le réseau
• Port d'attaque : TCP 445 (adresse IP publique du serveur)
• Authentification requise : non
• CVE : aucun identifiant CVE attribué au 24 octobre 2026

KSMBD ou Samba : comment savoir si vous êtes concerné

La distinction est essentielle, car la majorité des serveurs Linux et des systèmes d'exploitation de type Unix utilisent Samba, pas KSMBD :

Pour vérifier si le module KSMBD est chargé sur votre VPS ou serveur dédié Linux, connectez-vous en SSH et exécutez ces commandes en ligne de commande dans votre shell :

lsmod | grep ksmbd

Si la commande ne renvoie rien, le module n'est pas chargé : vous n'êtes pas exposé à ces deux failles critiques. Pour vérifier si le module est disponible dans la configuration du noyau (compilé mais non chargé) :

modinfo ksmbd 2>/dev/null && echo "Module disponible" || echo "Module absent"

Pour vérifier le port TCP 445 (SMB) depuis la ligne de commande, utilisez ss ou netstat pour lister les connexions en écoute sur votre adresse IP :

ss -tlnp | grep :445

Si vous utilisez Samba pour vos partages de fichiers (systemctl status smbd), ces deux vulnérabilités ne vous concernent pas. Samba est le choix par défaut sur la quasi-totalité des distributions Linux pour le partage de fichiers SMB/CIFS, y compris sur les VPS Linux utilisés pour héberger des serveurs de jeu ou des services web.

Les quatre autres vulnérabilités divulguées

Les six rapports ZDI incluent aussi quatre failles affectant d'autres sous-systèmes du noyau Linux. Aucune n'atteint le score CVSS 9.0 des deux failles KSMBD, mais elles restent exploitables sur un serveur dédié ou un VPS par un utilisateur local disposant d'un accès shell :

ZDI-CAN-33367 (skb_zerocopy) : la faille la plus largement exploitable

La faille skb_zerocopy mérite une attention particulière pour les administrateurs de serveurs partagés. Le bug se situe dans la fonction réseau skb_zerocopy du noyau : le drapeau SKBFL_SHARED_FRAG n'est pas propagé lors du transfert de pages entre les buffers de sockets. Un utilisateur local sans privilèges peut ainsi écrire dans le cache de pages de fichiers auxquels il n'a qu'un accès en lecture. L'exploitation, vérifiée avec les droits root obtenus, fonctionne sur AlmaLinux 8, 9 et 10, Debian 12 et 13, et Ubuntu 24.04 et 26.04, y compris en contournant les restrictions AppArmor. Un correctif a été soumis sur la liste netdev le 22 octobre, mais n'était pas encore fusionné dans le noyau principal au 24 octobre 2026.

La faille VMWGFX (ZDI-CAN-34068) concerne les environnements de virtualisation VMware. Si vous exploitez des machines virtuelles sur un serveur dédié avec un hyperviseur VMware, vérifiez que le pilote vmwgfx n'est chargé que dans les machines virtuelles qui utilisent l'accélération graphique virtuelle. Sur un serveur sans interface graphique (desktop), ce module n'a aucune raison d'être actif.

Mesures de mitigation immédiates

En attendant la publication des correctifs dans les paquets de sécurité de votre distribution, voici les actions à prendre sur chaque serveur Linux que vous administrez.

Vérifier et désactiver KSMBD

La grande majorité des serveurs Linux n'ont pas besoin de KSMBD. Les distributions AlmaLinux et Rocky Linux ne compilent même pas ce module. Sur Debian et Ubuntu, le module est compilé mais reste opt-in : il ne se charge pas sans une configuration explicite de l'admin. Si le module est chargé sans raison sur votre VPS, déchargez-le :

sudo modprobe -r ksmbd

Pour empêcher le chargement automatique au prochain redémarrage du système d'exploitation, créez un fichier de blacklist dans les répertoires de configuration de modprobe :

echo "blacklist ksmbd" | sudo tee /etc/modprobe.d/disable-ksmbd.conf
sudo update-initramfs -u

Après cette opération, redémarrer le serveur et vérifier avec lsmod | grep ksmbd que le module n'est plus chargé.

Configurer le firewall pour bloquer le port 445

Si vous devez conserver KSMBD actif, configurez votre firewall (pare-feu) pour bloquer l'accès au port TCP 445 depuis les adresses IP non autorisées. Avec UFW sur Ubuntu et Debian, la commande en ligne de commande est la suivante :

sudo ufw deny 445/tcp

Pour autoriser uniquement une adresse IP spécifique (par exemple un poste admin sur votre réseau local) :

sudo ufw allow from 192.168.1.100 to any port 445 proto tcp

Sur un serveur de jeu FiveM, Minecraft ou Rust, le port TCP 445 n'a aucune raison d'être ouvert sur l'interface publique. Consultez notre guide pour configurer les ports avec UFW sur un serveur Linux. Pour une configuration plus avancée avec nftables, consultez notre guide nftables : pare-feu pour serveur de jeu Linux.

Sauvegarder avant de mettre à jour le noyau

Avant d'appliquer un correctif du noyau Linux, créez un backup complet de votre serveur. Une mise à jour du noyau nécessite un redémarrage et peut, dans de rares cas, provoquer un problème de démarrage si la nouvelle version est incompatible avec vos configurations matérielles. Sauvegardez au minimum :

• Les fichiers de configuration critiques : /etc/ (configurations réseau, firewall, SSH, services)
• Les données applicatives : bases de données, répertoires de jeu, scripts personnalisés
• La liste des paquets installés : dpkg --get-selections > packages.list sur Debian et Ubuntu

Appliquer les mises à jour de sécurité du noyau

Surveillez les mises à jour de sécurité de votre distribution. Sur Ubuntu et Debian, activez les mises à jour automatiques de sécurité pour recevoir les correctifs du noyau dès leur publication par les mainteneurs de la distribution dans les dépôts de paquets. La commande pour vérifier et installer les paquets de sécurité en attente :

sudo apt update && sudo apt upgrade -y
# Vérifier la version du noyau après mise à jour :
uname -r

Après la mise à jour des paquets du noyau, vous devez redémarrer le serveur pour que le nouveau noyau soit chargé en mémoire RAM. Vérifiez que le système d'exploitation a bien démarré sur la nouvelle version avec uname -r depuis votre shell SSH. Pour les administrateurs qui compilent le noyau manuellement, surveillez les branches de développement du sous-système KSMBD sur git.kernel.org.

Statut des correctifs au 24 octobre 2026

Aucun identifiant CVE n'a encore été attribué aux six failles au 24 octobre 2026. Voici l'état des correctifs par composant :

Les distributions majeures (Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux) publient les correctifs de sécurité du noyau dans leurs dépôts de paquets une fois les patchs intégrés aux branches stables. Aucun avis de sécurité (advisory) n'avait été publié par ces distributions au 24 octobre. Sur un VPS géré, vérifiez que votre système applique bien les mises à jour de sécurité et sécurisez votre accès SSH pour limiter la surface d'attaque en attendant.

Script de vérification rapide

Ce script shell vérifie en une seule commande les principaux points d'exposition sur votre serveur Linux. Copiez-le dans votre terminal SSH :

echo "=== Noyau ==="
uname -r
echo "=== Module KSMBD ==="
lsmod | grep ksmbd || echo "Non chargé"
echo "=== Port 445 ==="
ss -tlnp | grep :445 || echo "Pas en écoute"
echo "=== Module VMWGFX ==="
lsmod | grep vmwgfx || echo "Non chargé"
echo "=== Samba (userspace) ==="
systemctl is-active smbd 2>/dev/null || echo "Inactif ou absent"
echo "=== Firewall UFW ==="
sudo ufw status 2>/dev/null || echo "UFW non installé"

Si KSMBD et le port 445 sont tous les deux absents, votre serveur n'est pas exposé aux deux failles critiques. Conservez ce script dans vos répertoires d'administration pour le relancer après chaque mise à jour du noyau.

Ce que ça change pour les administrateurs de serveurs

Pour un administrateur de VPS Linux ou de serveur dédié, cette divulgation rappelle trois principes fondamentaux de la sécurité du système d'exploitation :

• Réduisez la surface d'attaque du noyau. Chaque module noyau chargé est un vecteur potentiel. Si vous n'utilisez pas KSMBD, VMWGFX ou NVMET, désactivez-les via modprobe -r et ajoutez-les à la blacklist. Un serveur de jeu FiveM, Minecraft ou Rust n'a besoin d'aucun de ces modules pour fonctionner. Un VPS web hébergeant un serveur Apache ou Nginx non plus.
• Maintenez le noyau et les paquets à jour. Les failles du noyau Linux touchent tous les serveurs sous ce système d'exploitation, quel que soit l'hébergeur. Un VPS sous un noyau ancien cumule les vulnérabilités non corrigées. Planifiez un redémarrage régulier après chaque mise à jour de sécurité du noyau. Consultez notre article sur le noyau Linux 7.3 et ses implications pour les VPS et serveurs dédiés.
• Durcissez la configuration dès le premier jour. Firewall restrictif (seuls les ports nécessaires ouverts sur l'adresse IP publique), accès SSH par clé uniquement, comptes à privilèges minimaux, scripts de monitoring des connexions. Consultez notre guide pour sécuriser les premiers réglages d'un serveur dédié.

Pour surveiller les ressources de votre serveur (utilisation du processeur, de la RAM, de la bande passante réseau) après l'application des correctifs, consultez notre guide surveiller les ressources d'un VPS Linux avec htop et btop.