Deux failles du pilote Linux NVIDIA brisent l’isolation des GPU cloud depuis quatre ans

30 septembre 2026. Le NVD publie deux avis sur le pilote GPU Linux de NVIDIA, notés 7.8 (élevé). 12 novembre 2026. Le chercheur Stealthium lève l’embargo et leur donne un nom : ForgePtr et NvRoot. Pourquoi c’est important : ces failles vivent dans les modules noyau ouverts NVIDIA depuis quatre ans, et elles cassent précisément la promesse d’isolation qui fonde la location de GPU en cloud.

Deux failles, deux promesses d’isolation brisées

ForgePtr est enregistrée sous CVE-2026-47501. Dans la description du NVD, c’est une écriture hors limites (CWE-787) dans la couche mode noyau du pilote, déclenchée en fournissant des tampons mémoire incohérents lors de la mise en place d’un event buffer. La conséquence décrite par Stealthium est plus parlante : un processus non privilégié dans un conteneur GPU peut devenir root sur l’hôte.

NvRoot, enregistrée sous CVE-2026-47591, touche l’autorisation. Le NVD la décrit comme un contournement de la protection mémoire en lecture seule dû à une autorisation incorrecte (CWE-863) : un utilisateur non privilégié obtient l’écriture sur de la mémoire marquée en lecture seule. Traduit en termes d’infrastructure : le GPU peut réécrire des fichiers que le système d’exploitation a marqués en lecture seule, depuis n’importe quel tenant du nœud.

Ce sont deux formes d’une même maladie : la frontière qui sépare un tenant d’un autre — et un conteneur de son hôte — n’est pas étanche au niveau du pilote graphique. Et cette frontière est exactement ce qu’achète un client qui loue une tranche de GPU.

Un écart entre la note officielle et l’impact réel

La nuance mérite d’être posée, parce qu’elle change la lecture du risque. Le vecteur CVSS officiel des deux failles est CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H : vecteur local, faibles privilèges, portée inchangée. Autrement dit, le NVD — qui reprend l’évaluation du fournisseur — classe ces failles comme des élévations de privilèges à l’intérieur d’un même contexte de sécurité, et c’est ce qui justifie le score 7.8 plutôt qu’une note critique.

La publication de Stealthium raconte une autre histoire : un container escape vers le root de l’hôte, et une écriture croisée entre tenants. Si l’impact décrit est exact, la portée réelle est changée, pas inchangée — et la note opérationnelle, dans un environnement multi-tenant, se rapproche du critique. C’est un écart classique entre l’évaluation conservatrice d’un éditeur et la démonstration d’un chercheur tiers, et il faut le garder en tête avant de trier son parc.

Phoronix, qui relaie la divulgation, résume l’enjeu en une phrase : ces failles sont « particulièrement volatiles pour ceux qui louent des tranches de GPU dans le cloud ». Les fournisseurs de GPU cloud — qui font tourner plusieurs clients sur un même nœud physique — sont les premiers concernés.

Quatre ans de présence, des correctifs éparpillés

Les deux failles vivent dans les modules noyau ouverts NVIDIA depuis environ quatre ans — une durée qui dit deux choses : la complexité de la surface d’attaque d’un pilote graphique, et le faible taux de relecture sécurité de ce code jusqu’à récemment.

Les correctifs existent, mais ils sont répartis sur plusieurs branches de pilotes, ce qui complique le tri :

• NvRoot est corrigée par les pilotes 610.57.04, 595.91.07 et 580.178.04 ;
• ForgePtr est corrigée par le 615.71.09 — une branche dont nous avions déjà couvert l’apport fonctionnel en septembre, sans savoir qu’elle embarquait aussi ce correctif de sécurité.

La dispersion des correctifs n’est pas anodine. Un opérateur qui suit une branche long-term support (la 580.x ou la 595.x, par exemple) n’est pas nécessairement couvert contre ForgePtr, et devra vérifier s’il doit en plus monter une branche plus récente. La lecture attentive de l’avis de son fournisseur de pilotes s’impose.

Et vingt-cinq autres divulgations à venir

Le plus inquiétant arrive en fin d’annonce. Dans un message à Phoronix, Stealthium indique avoir 25 divulgations supplémentaires en réserve, ciblant cette fois la pile d’exécution IA de NVIDIA. Autrement dit, ForgePtr et NvRoot ne sont que les deux premières salves d’un stock plus large, et la fenêtre qui s’ouvre ne se refermera pas cette semaine.

C’est le second enseignement pour un SRE ou un RSSI : au-delà de ces deux CVE, il faut se préparer à une série de correctifs sur l’écosystème NVIDIA — pilote, mais aussi les composants de la pile CUDA et les runtimes d’inférence — dans les semaines qui viennent. La posture à adopter n’est pas « patcher ces deux-là », c’est « réactiver une veille pilote GPU continue ».

Ce que ça veut dire pour les loueurs de GPU

Ces deux failles touchent d’abord un modèle économique précis : la location de tranches de GPU, où plusieurs clients partagent le noyau d’un même nœud. C’est là que l’écart entre la note 7.8 et la démonstration de Stealthium coûte cher — un container escape vers le root de l’hôte, dans un environnement où l’hôte appartient au fournisseur et non au client, brise la promesse même qui justifie le partage.

Le point opérationnel qui en découle est rarement souligné : le tenant ne choisit pas la version du pilote. Dans un GPU cloud, c’est le fournisseur qui décide du binaire chargé, et donc de l’exposition de tous ses clients. La responsabilité — et l’urgence — est donc d’abord du côté des opérateurs de GPU cloud et des équipes qui mutualisent des nœuds en interne, avant d’être du côté du consommateur final.

Pour un consommateur, la question à poser à son fournisseur est simple et vérifiable : « quelle version de pilote tourne sur les nœuds que je loue, et couvre-t-elle 615.71.09 ? » La réponse est un bon test de la maturité sécurité du prestataire.

Vérifier et corriger

La vérification tient en une commande. Elle affiche la version du pilote installé, à comparer aux branches corrigées ci-dessus.

nvidia-smi --query-gpu=driver_version --format=csv,noheader

Si la version renvoyée est antérieure aux branches corrigées — et surtout si elle est inférieure à 615.71.09 — vous êtes dans la plage vulnérable. La correction de fond est la mise à jour du pilote via le dépôt de votre distribution, ou via l’installateur NVIDIA pour les parcs qui le gèrent manuellement. Sur des nœuds mutualisés, le tri doit croiser version du pilote et modèle d’isolation : si vos conteneurs GPU partagent le noyau de l’hôte, l’exposition à ForgePtr est directe.

Un rappel utile pour les environnements Kubernetes : les mises à jour de pilote exigent de vider les nœuds concernés, car le module noyau se recharge au redémarrage. Planifiez le déploiement en drainant les nœuds GPU un par un, plutôt que d’improviser une mise à jour à chaud.

Verdict

Si vous exploitez des GPU NVIDIA — et a fortiori si vous louez des tranches de GPU ou hébergez plusieurs tenants sur un même nœud — mettez à jour le pilote vers une branche corrigée avant votre prochaine fenêtre, en traitant ForgePtr (615.71.09) comme prioritaire car elle autorise l’évasion de conteneur vers l’hôte. Le score officiel 7.8 sous-estime l’impact réel en environnement mutualisé, et les 25 divulgations annoncées n’offrent aucune raison d’attendre. Si vous suivez une branche LTS, vérifiez explicitement qu’elle couvre les deux CVE — la dispersion des correctifs sur plusieurs branches rend l’hypothèse « je suis à jour donc je suis couvert » fausse ici.

Références

• Phoronix — « NVIDIA NvRoot & ForgePtr Vulnerabilities Published For Linux Driver, 25 More Coming » (Michael Larabel, 12 novembre 2026)
• NVD — CVE-2026-47501 (publiée le 30 septembre 2026)
• NVD — CVE-2026-47591 (publiée le 30 septembre 2026)
• ETTAYEB — « NVIDIA 615.71.09 apporte Reflex aux jeux Vulkan sous Proton et le partitionnement mémoire par cgroups »