Six failles dans le noyau Linux publiées « accidentellement » sur une liste publique Oups ? Illustration : Flock Vincent Hermann Le 23 octobre à 11h00 La Zero Day Initiative de Trend Micro a envoyé six rapports de failles de sécurité sur des listes de diffusion publiques du noyau Linux, avec de nombreux détails. Le caractère accidentel de ces publications est contesté.
Le danger, bien que limité, est réel pour certaines configurations. Une erreur ? Les 21 et 22 octobre, six rapports de vulnérabilités ont été envoyés par Trend Micro sur des listes publiques rattachées au développement du noyau public.
Plus précisément, ces rapports ont été adressés à la liste de sécurité privée du noyau, mais les listes publiques linux-kernel, linux-cifs, netdev et dri-devel figuraient en copie. Les détails techniques, avec les chemins de code et les traces KASAN, sont depuis publics alors qu’aucun correctif n’est encore publié. Six vulnérabilités, dont deux critiques Parmi les rapports, deux concernent des failles critiques dans ksmbd.
La première, estampillée par Trend Micro ZDI-CAN-33774, réside dans une situation de compétition dans l’affectation de la table de traitement. Si l’on envoie une rafale de paquets SMB1 courts suivie d’un paquet SMB2 dans la même écriture TCP, les processus de travail traitent alors les données SMB1 avec un gestionnaire SMB2, qui va lire au-delà de la mémoire tampon. Une écriture hors limites devient ainsi possible, à condition que le pirate ait accès à un partage, mais aucune autorisation n’est nécessaire, expliquant le score CVSS de 9 sur 10.
L’autre faille, ZDI-CAN-33549, est un dépassement par le bas d’un entier (integer underflow) dans le chemin SMB Direct de ksmbd. Un client peut envoyer des descripteurs de tampon RDMA dont le premier est plus long que la charge annoncée. Le compteur de taille du serveur repasse alors par zéro et une copie mémoire déborde ensuite du tampon alloué.
Pour l’exploitation en revanche, il faut réunir trois conditions : une interface compatible RDMA (matérielle ou le pilote logiciel rxe), un partage ksmbd accessible en écriture et un client qui négocie SMB Direct. À noter cependant que le support de SMB Direct est une option, désactivée par défaut. Le score CVSS est quand même de 9, confirmant la criticité de la brèche.
Ces notes sont attribuées via CVSS 3.1, le caractère critique débutant à 9. Trois autres failles – ZDI-CAN-33367, ZDI-CAN-34068 et ZDI-CAN-34076 – sont tout de même dans la tranche élevée, avec des notes comprises entre 7,8 et 8,8. Elles concernent respectivement une élévation locale de privilèges dans skb_zerocopy (réseau), une élévation locale de privilèges dans le pilote de GPU virtuel vmwgfx (VMware) et une divulgation d’informations dans nvmet (un pilote NVMe).
La sixième faille, ZDI-CAN-32005, est un dépassement de pile (stack overflow) dans ConnMan, mais aucun score CVSS n’est rattaché. Bien que le danger soit limité à certaines configurations spécifiques (ksmbd est un serveur compatible Samba mais n’est pas Samba), il est réel. Dans le contexte de publication de ces failles, il est probable qu’aucun correctif ne sera disponible avant plusieurs semaines.
Accident ou respect des nouvelles règles du noyau ? Phoronix est le premier site à s’être rendu compte de ces publications. Pour nos confrères, il s’agissait clairement d’une bourde importante.
D’ailleurs, Greg Kroah-Hartman en personne, le mainteneur principal du noyau Linux, s’est étonné et agacé dans des réponses à ces publications. Sur le pilote GPU VMware par exemple, il a répondu : « Pour une raison quelconque, vous avez envoyé cela dans des listes publiques, sans correctif, donc nous ne pouvons pas faire grand-chose avec ça ». L’agacement est monté d’un cran sur le rapport du pilote NMVe : « Encore une fois, pas de correctif, et envoyé sur une liste publique ?
Merci de corriger votre processus de soumission… ». Mais en dépit de ces réponses, certains médias s’interrogent : s’agissait-il vraiment d’un accident ? Cyber Kendra note ainsi que les rapports attribuent clairement la découverte des failles à TrendAI, le scanner IA de vulnérabilités de Trend Micro.
Or, selon la documentation sur les failles de sécurité dans le noyau, réécrite et fusionnée pour le noyau Linux 7.1, indique que toute vulnérabilité trouvée grâce à l’IA doit être considérée comme publique et envoyée aux mainteneurs concernés plutôt que sur la liste privée. Nos confrères rappellent que cette règle est une conséquence directe de l’agacement de Linus Torvalds sur le caractère « presque totalement ingérable » de la liste privée de sécurité depuis l’émergence des outils IA. Mais selon ces mêmes directives, les découvreurs de failles doivent joindre des correctifs ou des analyses d’impact.
Les rapports de Trend Micro ne contenaient ni l’un ni l’autre, expliquant en partie l’agacement de Greg Kroah-Hartman. The Hacker News évoque les mêmes règles et ne mentionne d’ailleurs jamais le caractère éventuellement accidentel de ces publications. Nous avons contacté Trend Micro et mettrons à jour cette actualité si nous obtenons une réponse.
Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant. Accédez en illimité aux articles d'un média expert Profitez d'au moins 1 To de stockage pour vos sauvegardes Intégrez la communauté et prenez part aux débats Partagez des articles premium à vos contacts Abonnez-vous bilbonsacquet Premium Aujourd'hui à 11h34 Message 1 Signaler Bloquer cet utilisateur Côté curl, Daniel Stenberg a décidé que toutes les failles non critiques doivent désormais être publiques :https://daniel.haxx.se/blog/2026/10/20/do-minor-curl-vulnerabilities-in-the-open/Le but étant qu’une même faille ne soit pas remontée une multitude de fois ce qui arrive très souvent avec l’utilisation de LLM Signaler un commentaire Voulez-vous vraiment signaler ce commentaire ?
Non Oui