GPUThor : des GPU NVIDIA vulnérables à Rowhammer malgré l'ECC

Dans le cadre de notre veille sécurité, nous revenons sur GPUThor, une nouvelle attaque Rowhammer visant la mémoire de certains GPU NVIDIA.

Le résultat mérite l’attention des exploitants : les chercheurs de l’Université de Toronto ont réussi à provoquer suffisamment de corruptions mémoire pour dépasser la protection ECC, déclencher des indisponibilités et obtenir une élévation de privilèges jusqu’à root sur l’hôte.

Le sujet concerne directement certaines infrastructures de calcul, notamment les plateformes GPU mutualisées et les serveurs utilisés pour entraîner ou héberger des modèles d’intelligence artificielle. Il faut cependant poser immédiatement une limite importante : une simple requête envoyée à une API LLM ne suffit pas à exploiter GPUThor. L’attaquant doit pouvoir exécuter son propre code CUDA sur le GPU.

GPUThor amplifie fortement les attaques Rowhammer sur GPU

Rowhammer exploite un défaut physique de la mémoire DRAM. En activant très rapidement certaines lignes de mémoire, un programme peut perturber les cellules voisines et modifier la valeur de certains bits sans écrire directement dans leur emplacement.

Les premières attaques Rowhammer visant les GPU produisaient relativement peu de corruptions. L’activation de l’ECC, capable de corriger une erreur simple et de détecter certaines erreurs multiples, constituait donc une protection importante.

GPUThor change cette appréciation en utilisant des motifs d’accès non uniformes. Les lignes proches de la cible sont sollicitées bien plus intensément que les lignes leurres utilisées pour contourner les mécanismes internes de rafraîchissement. Les chercheurs ont également étudié la manière dont les GPU regroupent les accès mémoire afin d’éviter que ces requêtes répétées soient fusionnées avant d’atteindre la GDDR6.

Le motif obtenu sollicite la ligne visée environ 6,6 fois plus intensément que les approches précédentes. Selon l’étude, GPUThor produit entre 500 et 23 500 fois plus de bit flips que les attaques GPU antérieures auxquelles il est comparé.

Cette progression ne représente pas seulement un meilleur résultat de laboratoire. Elle rend possibles des corruptions multibits que l’ECC employé sur les GPU testés ne sait pas toujours corriger.

L’ECC reste utile, mais ne constitue plus une défense suffisante

Sur la RTX A6000 testée avec l’ECC activé, les chercheurs ont observé deux types de situations problématiques.

Une erreur sur deux bits peut être détectée sans être corrigée. Le GPU interrompt alors les traitements en cours et doit être réinitialisé. Durant la campagne présentée, l’équipe a provoqué en moyenne une erreur non corrigible toutes les deux heures sur la carte étudiée. Pour une plateforme d’inférence, un tel événement peut interrompre plusieurs traitements, vider les tâches en cours et rendre le GPU indisponible pendant sa récupération.

Une corruption portant sur davantage de bits peut aussi tromper le mécanisme de correction et produire une corruption silencieuse des données. Le traitement continue alors avec une valeur erronée, sans nécessairement générer l’alerte attendue.

Les chercheurs ont enfin corrompu les tables de pages du GPU et obtenu un accès arbitraire à la mémoire, puis un shell root sur l’hôte. L’exploitation avec ECC activé a nécessité une phase de profilage hors ligne de plusieurs jours sur leur A6000, tandis que la phase active s’est exécutée en moins de deux minutes.

Ce détail est important pour qualifier le risque : GPUThor démontre une compromission sérieuse, mais il ne s’agit pas d’une exécution de code distante instantanée et universelle.

Un serveur hébergeant un LLM peut-il être concerné ?

Oui, lorsque son modèle d’usage permet à un acteur non fiable d’exécuter du code sur le GPU.

Le scénario le plus exposé est celui d’une plateforme de calcul mutualisée sur laquelle plusieurs clients, équipes ou chercheurs peuvent soumettre leurs propres tâches CUDA. L’attaquant dispose alors de la capacité nécessaire pour exécuter un kernel conçu pour solliciter la mémoire.

Les environnements suivants doivent être examinés en priorité :

• services de notebooks accessibles à plusieurs utilisateurs ;
• clusters de calcul ou d’entraînement partagés entre différentes équipes ;
• offres GPU cloud exécutant les conteneurs ou images de leurs clients ;
• plateformes MLOps acceptant des modèles accompagnés de code personnalisé ;
• runners CI disposant d’un accès direct au GPU ;
• serveurs qui installent automatiquement des dépendances fournies avec un modèle ;
• postes ou serveurs sur lesquels plusieurs comptes locaux peuvent lancer des programmes CUDA.

Dans un environnement mono-utilisateur, le risque ne disparaît pas complètement. Une dépendance compromise, une image de conteneur non maîtrisée ou du code personnalisé récupéré avec un modèle peut fournir le point d’entrée local nécessaire. GPUThor devient alors une voie possible pour sortir des permissions accordées au processus et atteindre l’hôte.

Cette question rejoint un principe plus large : héberger localement un modèle ne suffit pas à maîtriser ses données et sa sécurité. Il faut aussi maîtriser les images, les dépendances, le code associé au modèle et les droits accordés au runtime.

Une API d’inférence fermée n’offre pas directement le même scénario

Un internaute qui envoie une question à une API d’inférence ne contrôle normalement ni les instructions CUDA, ni les adresses mémoire utilisées par le GPU. La requête est interprétée par un moteur déjà déployé, avec un modèle et une chaîne logicielle choisis par l’exploitant.

Dans cette configuration, GPUThor ne doit donc pas être présenté comme une faille exploitable à partir d’un simple prompt.

Le niveau d’exposition change si l’API permet aussi :

• d’importer un modèle arbitraire ;
• de charger du code personnalisé ;
• d’exécuter un notebook ou un conteneur ;
• d’installer des paquets à la demande ;
• d’accéder directement à CUDA ou au périphérique GPU.

La bonne question n’est pas uniquement « ce serveur héberge-t-il un LLM ? », mais plutôt : qui peut faire exécuter quoi sur le GPU physique ?

Quatre GPU Ampere avec GDDR6 ont été testés

Les chercheurs ont confirmé des bit flips sur quatre GPU professionnels NVIDIA de génération Ampere équipés de mémoire GDDR6 :

• RTX A4000 ;
• RTX A4500 ;
• RTX A5000 ;
• RTX A6000.

Les densités observées varient fortement selon les cartes. La RTX A5000 a présenté le plus grand nombre de corruptions dans leur campagne avec ECC désactivé. Les essais détaillés avec ECC activé ont en revanche été réalisés sur une RTX A6000 locale, les autres cartes étant utilisées dans un cloud qui ne permettait pas d’activer cette option.

Il faut donc éviter deux raccourcis :

• le résultat ne concerne pas automatiquement tous les GPU NVIDIA ;
• l’absence de bit flip observé avec un motif donné ne prouve pas qu’une autre variante ne fonctionnera jamais.

Les chercheurs indiquent ne pas avoir obtenu de corruption avec leurs motifs actuels sur les autres types de mémoire testés, dont HBM, GDDR6X et GDDR7. NVIDIA précise de son côté qu’aucun bit flip n’a été observé sur les GPU testés avec GDDR6X ou HBM2e dans les mêmes conditions.

Les A100 et H100, souvent utilisés pour les grands modèles, ne font donc pas partie des quatre GPU sur lesquels GPUThor a démontré des corruptions. Il serait néanmoins excessif de transformer cette absence de démonstration en garantie définitive pour toutes les mémoires HBM et toutes les générations.

L’intégrité des modèles et des résultats entre aussi dans le périmètre

Le déni de service et l’élévation de privilèges sont les impacts les plus directs démontrés par GPUThor. Pour une infrastructure IA, la corruption silencieuse mérite la même attention.

Des travaux Rowhammer antérieurs sur GPU ont déjà montré qu’une modification de bits dans les poids d’un modèle pouvait dégrader sa précision. GPUThor n’est pas présenté comme une attaque spécifique contre les LLM, mais il augmente fortement la capacité à provoquer des corruptions dans la mémoire GPU.

Selon la donnée touchée, les conséquences peuvent dépasser le simple plantage : résultat d’inférence incorrect, état de calcul altéré, poids chargés en mémoire modifiés ou comportement difficilement reproductible. Ce risque d’intégrité est par nature plus délicat à détecter qu’une réinitialisation franche du GPU.

Comment qualifier l’exposition d’une infrastructure GPU

La première étape consiste à inventorier précisément le matériel réellement installé :

nvidia-smi --query-gpu=index,name,uuid,memory.total,ecc.mode.current,ecc.mode.pending --format=csv

Il faut ensuite documenter le modèle d’accès :

• le GPU est-il dédié à une seule application ou partagé ;
• plusieurs domaines de confiance utilisent-ils la même carte ;
• les utilisateurs peuvent-ils fournir leur propre conteneur ;
• un service autorise-t-il l’exécution de notebooks ;
• des modèles sont-ils chargés avec du code personnalisé ;
• les dépendances sont-elles épinglées, vérifiées et construites dans une chaîne maîtrisée ;
• le périphérique GPU est-il accessible à des conteneurs qui n’en ont pas besoin.

Cette cartographie est plus utile qu’une conclusion fondée uniquement sur le nom du modèle de GPU.

Les mesures à appliquer maintenant

Il n’existe pas de correctif logiciel universel capable de réparer une faiblesse physique de la mémoire déjà installée. La réponse repose donc sur plusieurs couches complémentaires.

Activer l’ECC sans le considérer comme une garantie absolue

L’étude ne rend pas l’ECC inutile. Il continue de corriger de nombreuses erreurs simples et transforme certaines corruptions en erreurs détectables plutôt qu’en altérations silencieuses.

Il faut vérifier son état réel et pas seulement la configuration attendue. Une modification du mode ECC peut nécessiter un redémarrage avant de devenir active.

Vérifier l’IOMMU et l’isolation DMA

NVIDIA recommande d’activer l’IOMMU sur les hôtes qui exécutent des charges GPU sensibles. Sous Linux, une première vérification peut être réalisée avec :

dmesg | grep -i -E 'DMAR|IOMMU'

Le bulletin NVIDIA estime qu’une isolation DMA correctement configurée peut bloquer ou limiter le chemin vers la mémoire privilégiée de l’hôte. L’étude rapporte toutefois une élévation de privilèges dans son environnement avec l’IOMMU activée. Il faut donc voir cette mesure comme une couche de défense à configurer et tester, pas comme une preuve suffisante d’immunité.

Ne pas partager un GPU entre domaines de confiance différents

Lorsqu’un client ou un utilisateur peut soumettre son propre code CUDA, le partage du même GPU physique avec des traitements sensibles augmente directement le risque.

Une séparation par files de tâches ou par conteneurs ne modifie pas nécessairement le domaine physique de la mémoire. Pour les périmètres les plus sensibles, l’isolation doit être pensée au niveau de la carte ou du noeud, avec un ordonnancement qui évite la cohabitation entre acteurs non fiables.

Maîtriser le code exécuté avec les modèles

Un modèle récupéré depuis Internet ne doit pas conduire automatiquement à exécuter son code auxiliaire avec accès au GPU. Les images de conteneurs, dépendances Python, extensions CUDA et scripts de chargement doivent suivre les mêmes règles qu’un composant applicatif : origine connue, versions maîtrisées, revue et droits minimaux.

Superviser la télémétrie de fiabilité

NVIDIA recommande de surveiller les erreurs ECC corrigées et non corrigées, les remappages de lignes et les réinitialisations inattendues. Une vue détaillée peut être obtenue, selon les capacités du matériel et du pilote, avec :

nvidia-smi -q -d ECC,PAGE_RETIREMENT,ROW_REMAPPER

Ces informations doivent rejoindre la supervision habituelle de l’hôte : événements Xid du pilote, disparition d’un GPU, arrêt des kernels, redémarrage du service d’inférence et baisse anormale de capacité.

La surveillance n’est pas une barrière parfaite. Les chercheurs signalent notamment que certaines corruptions silencieuses peuvent ne pas déclencher les compteurs attendus. Elle reste néanmoins indispensable pour détecter une activité anormale ou un matériel qui se dégrade.

Préparer la perte temporaire d’un GPU

Sur un service d’inférence critique, la résilience ne peut pas dépendre d’une seule carte. Il faut prévoir le drainage du noeud, la reprise des tâches, le redémarrage contrôlé du GPU ou de l’hôte et, lorsque le besoin le justifie, une capacité de secours.

Ce travail relève autant de la conception de l’infrastructure que de la sécurité pure.

Notre lecture opérationnelle

GPUThor ne signifie pas que tous les serveurs LLM sont immédiatement exploitables. Il montre en revanche que le GPU doit être considéré comme une surface de sécurité à part entière, et pas uniquement comme un accélérateur attaché à un serveur Linux.

Pour un exploitant, les priorités sont claires :

1. identifier les modèles de GPU et les types de mémoire présents ;
2. déterminer qui peut réellement exécuter du code CUDA ;
3. supprimer les partages inutiles entre domaines de confiance ;
4. vérifier ECC, IOMMU et isolation DMA ;
5. intégrer les erreurs GPU et les resets dans la supervision ;
6. contrôler la chaîne d’approvisionnement des modèles, conteneurs et dépendances ;
7. documenter la procédure de retrait et de reprise d’un noeud GPU.

À la date de publication de cet article, le code et les artefacts GPUThor ne sont pas encore publics. Leur publication est annoncée pour le 15 novembre 2026. Cela limite la reproduction immédiate de l’attaque, mais ne change ni la faiblesse démontrée, ni la nécessité de qualifier les environnements concernés.

Cette démarche correspond au rôle d’une veille de sécurité intégrée à l’exploitation : transformer une publication de recherche en inventaire, décisions d’architecture, supervision et procédures vérifiables.

Conclusion

GPUThor démontre qu’une attaque Rowhammer peut dépasser l’ECC sur une RTX A6000, provoquer des arrêts de traitements et mener à une élévation de privilèges sur l’hôte. Des bit flips ont également été confirmés sur les RTX A4000, A4500 et A5000.

Les serveurs LLM ne sont pas vulnérables du seul fait qu’ils répondent à des prompts. Le risque devient concret quand une personne ou une chaîne logicielle non fiable peut exécuter du code CUDA sur le GPU.

La réponse ne tient donc pas dans une option unique : il faut combiner choix du matériel, cloisonnement des usages, ECC, isolation DMA, maîtrise des dépendances, observabilité et capacité de reprise.

Si vous souhaitez qualifier l’exposition de vos serveurs GPU ou revoir l’isolation et la supervision de votre infrastructure Linux, nous pouvons vous accompagner dans le cadre de notre infogérance Linux.

• Découvrir notre offre d’infogérance Linux
• Nous contacter
• Prendre rendez-vous

Sources

• GPUThor - présentation des chercheurs
• GPUThor - publication scientifique
• NVIDIA - Security Notice Rowhammer, août 2026
• NVIDIA - documentation nvidia-smi

FAQ : GPUThor et la sécurité des serveurs GPU

Qu’est-ce que GPUThor ?

GPUThor est une attaque Rowhammer qui utilise des motifs d’accès mémoire non uniformes pour provoquer de nombreux bit flips dans la mémoire GDDR6 de certains GPU NVIDIA, y compris lorsque l’ECC est activé.

Quels GPU sont affectés par GPUThor ?

Les chercheurs ont confirmé des bit flips sur les NVIDIA RTX A4000, A4500, A5000 et A6000. L’exploitation avec ECC activé a été démontrée sur une RTX A6000. Cela ne permet pas de généraliser automatiquement le résultat à tous les GPU NVIDIA.

Une requête envoyée à un serveur LLM suffit-elle pour exploiter GPUThor ?

Non. L’attaque suppose que l’attaquant puisse exécuter un kernel CUDA sur le GPU. Une API d’inférence qui accepte uniquement des requêtes textuelles et n’autorise ni code, ni modèle, ni conteneur non maîtrisé n’offre normalement pas cette capacité.

L’activation de l’ECC protège-t-elle contre GPUThor ?

L’ECC reste utile, mais ne suffit pas seul. Les chercheurs ont provoqué sur une RTX A6000 des erreurs multibits que l’ECC pouvait détecter sans les corriger, ainsi qu’une corruption silencieuse. NVIDIA recommande de combiner ECC, isolation DMA, choix du matériel, cloisonnement et supervision.

Comment réduire le risque GPUThor sur un serveur GPU ?

Il faut inventorier les GPU et leur mémoire, limiter l’exécution de code CUDA non fiable, éviter le partage physique entre domaines de confiance différents, activer l’ECC et l’IOMMU, puis superviser les erreurs ECC, remappages de lignes et réinitialisations.