Corruption mémoire et 6 failles critiques du noyau Linux : faut-il passer votre Steam Deck et SteamOS en canal Bêta ?
La procédure habituelle de divulgation coordonnée au sein du noyau Linux suit une règle d’or immuable : un chercheur signale une faille en privé à l’équipe de sécurité (security@kernel.org), les mainteneurs développent et valident un correctif en coulisses, puis le détail technique est rendu public une fois la mise à jour déployée. Entre le 21 et le 22 octobre 2026, cette chaîne de protection a volé en éclats. Six rapports de vulnérabilités sévères issus de la Zero Day Initiative (ZDI) de Trend Micro ont atterri directement sur la liste de diffusion publique du noyau Linux (LKML) avant même qu’un correctif officiel ne soit fusionné dans la branche principale. Avec des scores grimpant jusqu’à 9.0 sur 10 sur l’échelle CVSS, cette exposition soudaine pousse de nombreux joueurs sous SteamOS, Bazzite ou Nobara à s’interroger sur l’opportunité de basculer leur Steam Deck et leur PC gaming Linux vers les branches Bêta.
Six vulnérabilités exposées au grand jour et la réaction immédiate de Greg Kroah-Hartman
L’apparition successive de ces six rapports complets sur les archives publiques de lore.kernel.org a immédiatement fait réagir Greg Kroah-Hartman, bras droit de Linus Torvalds et mainteneur historique des branches stables du noyau Linux. En quelques minutes, ce dernier a répondu individuellement à chacune des soumissions de la Zero Day Initiative pour leur demander pourquoi des failles non corrigées étaient ainsi livrées en pâture sur un canal public sans le moindre patch attaché.
Un détail technique intrigue particulièrement les observateurs au cœur des rapports publiés : plusieurs d’entre eux créditent TrendAI, le scanner automatisé de vulnérabilités par intelligence artificielle de Trend Micro, comme découvreur initial. Or, depuis mai 2026 et la sortie du noyau Linux 7.1, la documentation officielle des bugs de sécurité réécrite par Willy Tarreau à la demande de Linus Torvalds impose une nouvelle doctrine : face à l’afflux massif de rapports générés par IA qui saturait la liste privée, toute faille découverte par un outil automatisé d’IA est considérée comme déjà publique et doit être envoyée aux mainteneurs sur les listes ouvertes, mais accompagnée d’un correctif ou d’une analyse d’impact précise. En expédiant des avis de vulnérabilité bruts sans correctif sur la liste publique, la ZDI a exposé des vecteurs d’attaque critiques avant même l’attribution d’identifiants CVE officiels.
Le détail technique des 6 failles ZDI : de KSMBD à la pile réseau du noyau
Toutes les vulnérabilités divulguées lors de cet incident ne présentent pas le même profil de risque pour une console portable ou un PC de jeu. Voici le décryptage exact des six identifiants publiés sur la liste du noyau :
- ZDI-CAN-33549 (Score CVSS 9.0, exécution de code à distance) : un dépassement d’entier par le bas (integer underflow) dans le chemin SMB Direct (RDMA) du module KSMBD, le serveur de fichiers SMB3 intégré directement au noyau Linux. Lorsqu’un client transmet des descripteurs de mémoire RDMA dont la première entrée excède la taille de charge utile déclarée, le compteur interne boucle vers une valeur colossale et provoque un écrasement de mémoire tampon. Un correctif était déjà en préparation dans une branche Git destinée à Linux 7.5 et fait désormais l’objet d’un rétroportage accéléré vers la branche principale.
- ZDI-CAN-33774 (Score CVSS 9.0, exécution de code à distance sans authentification) : une condition de concurrence (race condition) critique dans la sélection du gestionnaire de protocole de KSMBD, démontrée sur le noyau Linux 7.3-rc3. En envoyant une rafale de paquets SMB1 courts suivie d’une requête SMB2 dans la même écriture TCP sur le port 445, un attaquant distant force le fil d’exécution SMB2 à lire au-delà du tampon SMB1, entraînant une fuite de mémoire du tas (kernel heap) ainsi qu’une écriture hors limites lors de l’analyse des descripteurs de sécurité.
- ZDI-CAN-33367 (Score CVSS 7.8, élévation locale de privilèges) : une faille logée au cœur du code réseau du noyau Linux, plus précisément dans la gestion de la fonction de copie zéro des tampons de sockets (
skbuff/skb-zerocopy). Les développeurs du noyau avaient déjà reçu un signalement distinct d’un autre chercheur une semaine plus tôt sur ce même bogue, et un correctif est en phase finale de validation. - ZDI-CAN-34068 (Score CVSS 8.8, élévation locale de privilèges) : une écriture hors limites (out-of-bounds write) dans le pilote graphique virtuel vmwgfx, utilisé au sein des machines virtuelles VMware sous Linux.
- ZDI-CAN-34076 (Score CVSS 8.6, divulgation d’informations) : l’exploitation d’une ressource non initialisée dans le pilote cible NVMe over Fabrics (nvmet) du noyau, susceptible d’exposer des données résiduelles en mémoire.
- ZDI-CAN-32005 (Élévation locale de privilèges) : un dépassement de tampon sur la pile (stack buffer overflow) lors du traitement des requêtes TCP liées aux domaines de recherche dans ConnMan, le gestionnaire de connexion réseau léger utilisé en espace utilisateur sur de nombreuses distributions embarquées.
Quel impact concret sur SteamOS, le Steam Deck et les distributions gaming Linux ?
Face à ces scores CVSS de 9.0 et aux récentes alertes de sécurité ayant touché les infrastructures web, faut-il craindre une prise de contrôle à distance de votre Steam Deck ou de votre machine sous Bazzite ? Sur le volet des deux failles les plus sévères (ZDI-CAN-33549 et ZDI-CAN-33774), une distinction capitale s’impose : le module KSMBD n’est pas Samba. Développé à l’origine par Samsung pour offrir un serveur SMB3 directement dans l’espace noyau, KSMBD est désactivé par défaut sur l’immense majorité des distributions de bureau et n’est pas exécuté sur un Steam Deck standard qui ne partage pas de fichiers via le port 445 en mode serveur noyau. Seuls les boîtiers NAS domestiques, mini-serveurs ou machines sur lesquels l’utilisateur a manuellement activé ksmbd-tools sur un réseau non fiable sont directement exposés.
En revanche, la vulnérabilité d’élévation locale de privilèges dans la pile réseau (ZDI-CAN-33367) et celle affectant le démon réseau ConnMan (ZDI-CAN-32005) touchent des composants beaucoup plus répandus. Si vous utilisez régulièrement votre Steam Deck en mode Bureau (KDE Plasma) sur des réseaux Wi-Fi publics, que vous installez des paquets tiers en dehors du bac à sable Flatpak ou que vous exécutez des scripts communautaires, l’application rapide des correctifs du noyau reste la meilleure barrière.
Voir les disponibilités Valve Steam Deck OLED sur Amazon→
Comment activer le canal Bêta sur SteamOS et vérifier votre système Linux
Étant donné que plusieurs correctifs destinés à combler ces brèches transitent d’abord par les branches de test (linux-next et candidats de publication) avant d’être intégrés aux versions stables, basculer temporairement sur un canal de mise à jour anticipé permet de récupérer plus vite les révisions du noyau Linux déployées par Valve, un suivi logiciel étroit qui prépare déjà le terrain pour la future architecture AMD Zen 6 repérée sous Linux pour le prochain Steam Deck.
Pour passer votre Steam Deck (LCD ou OLED) sur une branche plus récente de SteamOS :
- Appuyez sur le bouton physique STEAM de votre console portable pour ouvrir le menu principal.
- Rendez-vous dans la rubrique Paramètres, puis descendez jusqu’à l’onglet Système.
- Dans la section Participation aux bêta, sélectionnez le menu déroulant Canal de mise à jour du système.
- Choisissez le canal Bêta (ou Préversion / Preview qui embarque les dernières révisions du noyau Linux 7.2 et les correctifs amont d’Arch Linux), appliquez le téléchargement puis redémarrez la machine.
Sur un PC gaming Linux classique ou dans Konsole en mode Bureau sur SteamOS, vous pouvez également vérifier en une seconde qu’aucun module serveur KSMBD n’est actif en tapant lsmod | grep ksmbd. Si le module apparaît chargé alors que vous n’hébergez aucun partage réseau noyau, déchargez-le immédiatement via la commande sudo modprobe -r ksmbd et bloquez le port TCP 445 dans votre pare-feu.
Mon banc d’essai : faut-il vraiment quitter le canal Stable de votre Steam Deck aujourd’hui ?
À mon sens, il faut garder la tête froide et distinguer l’usage réel de sa machine avant de se précipiter sur une branche expérimentale. Sur mon propre Steam Deck OLED, tant que la console reste utilisée comme une machine de jeu dédiée derrière le routeur NAT de la maison, les deux failles critiques à 9.0 sur KSMBD n’ont aucune prise puisque ce serveur de fichiers noyau n’y tourne tout simplement pas. En revanche, pour un joueur qui utilise son Steam Deck comme un véritable PC portable sous Linux en déplacement, connecté à des réseaux partagés avec de multiples outils en mode Bureau, la faille d’élévation de privilèges réseau dans skbuff justifie pleinement de surveiller de très près les notes de patch du canal Bêta de SteamOS cette semaine. L’ironie de cette affaire reste tout de même savoureuse : en voulant désengorger la liste privée des rapports générés par l’IA, la nouvelle politique du noyau Linux vient de provoquer exactement ce que la divulgation coordonnée cherchait à éviter depuis vingt ans.
Retrouvez Pro-Gamer en priorité sur Google
Ajoutez pro-gamer.fr à vos sources préférées pour retrouver nos guides et actus directement dans votre flux Google Discover et vos résultats de recherche.
Passionné de hardware et de jeu vidéo, Arthur « Heimdall » navigue entre la France et l'Angleterre où il travaille dans la vente de solutions logicielles B2B. Diplômé d'école de commerce et passionné de bancs d'essai, il monte et démonte des PC depuis son enfance, traquant chaque degré thermique et chaque milliseconde de latence d'affichage. Joueur éclectique passé par Assassin's Creed et Roblox, c'est sur les raids de World of Warcraft qu'il a rencontré Grimtag et Chaya avant de rejoindre l'aventure Pro-Gamer.
