GPUThor contourne l’ECC des GPU NVIDIA et remonte en root depuis un noyau CUDA

25 août 2026. 1,1 minute. 377 000 flips par Go. Des chercheurs de l’université de Toronto ont publié GPUThor, une attaque Rowhammer qui contourne le correcteur d’erreurs ECC des GPU NVIDIA de classe Ampere pour déclencher un déni de service ou une élévation de privilèges jusqu’au root. Le bit exploitable se trouve en 1,1 minute là où l’attaque précédente de la même équipe, GPUHammer, exigeait 21,9 heures. Le message est simple : la seule mitigation sur laquelle les opérateurs de clusters GPU s’appuyaient est désormais contournable.

Ce que GPUThor change par rapport aux attaques précédentes

Rowhammer désigne une famille d’attaques où l’on « martèle » des lignes mémoire voisines pour provoquer des flips de bits — un état qui passe de 0 à 1 ou l’inverse. Depuis des années, l’ECC faisait office de rempart : les GPU récents corrigent les erreurs à bit unique (SECDED) et détectent les erreurs à double bit. GPUHammer puis GPUBreach étaient devenus sans intérêt pratique précisément parce que l’ECC les neutralisait.

GPUThor change la donne en s’appuyant sur deux comportements non documentés des GPU : la façon dont les requêtes mémoire répétées sont coalescées, et la fréquence à laquelle le Target Row Refresh (TRR) s’active. En ajustant le motif de martèlement pour qu’il reste non uniforme et sous le seuil de déclenchement du TRR, les chercheurs obtiennent 6,6 fois plus d’activations de lignes agresseuses que les concepts précédents.

Les chiffres sont sans ambiguïté. Sans ECC, GPUThor génère entre 72 000 et 377 000 flips par Go sur les cartes testées — soit de 4 548 à 23 597 fois plus que GPUHammer — et approche les taux des meilleures attaques Rowhammer sur CPU, comme Blacksmith. Avec l’ECC activée, l’attaque produit 387 erreurs à double bit que l’ECC détecte sans pouvoir corriger, et deux erreurs à triple bit que le correcteur répare à tort, provoquant une corruption silencieuse.

DoS puis élévation de privilèges

Les chercheurs ont démontré deux conséquences concrètes sur une RTX A6000 équipée d’ECC. La première est un déni de service : le GPU se réinitialise toutes les deux heures, interrompant toute charge de travail, et finit par se marquer comme à remplacer après des répétitions.

La seconde est plus grave : en corrompant les tables de pages du GPU, un programme CUDA non privilégié obtient un accès mémoire arbitraire et ouvre un shell root sur la machine hôte. C’est le scénario que les opérateurs redoutent le plus, car il transforme un simple job soumis à une file d’exécution en compromission du nœud entier.

La surface ne se limite pas aux cartes de station de travail testées — RTX A4000, A4500, A5000 et A6000 en GDDR6. Les chercheurs précisent que l’élévation de privilèges fonctionne aussi sur les GPU serveur A100, toujours en SECDED. Sur certaines cartes Blackwell, la fonction RAS Repair rend l’attaque plus lente sans l’empêcher. Et les mémoires HBM3e ou GDDR7 avec ECC on-die pourraient rester vulnérables si des flips multi-bits sont déclenchés.

La réponse NVIDIA et les limites

Les chercheurs ont signalé leurs travaux à NVIDIA le 29 avril 2026. Le 21 août, l’éditeur a publié un advisory avec des recommandations : activer à la fois SYS-ECC et l’isolation IOMMU/DMA, surveiller la télémétrie d’erreurs du GPU, et restreindre le partage ou l’exécution de charges non fiables. NVIDIA note que le risque varie selon le composant DRAM, la technologie mémoire, la conception de la plateforme et les défenses embarquées — et qu’aucun flip n’a été observé sur les GPU GDDR6X ou HBM2e testés avec les mêmes motifs.

Cette réponse circonscrit le problème sans le refermer. L’ECC, qu’on présentait comme une garantie, devient un détecteur : il signale une corruption qu’il ne sait pas toujours corriger. La protection durable passera par un ECC multi-bits renforcé et des défenses matérielles de nouvelle génération — pas avant la prochaine architecture.

Du CPU au GPU : une décennie de Rowhammer

Rowhammer n’est pas une nouveauté. La technique a été décrite pour la première fois en 2014, sur la DRAM des CPU : en martelant une rangée de mémoire, on provoque des flips de bits dans les rangées voisines, et ces flips finissent par contourner les protections logicielles. Sur CPU, la recherche a enchaîné les variantes — TRRespass, SMASH, puis Blacksmith — qui ont chacune repoussé une mitigation matérielle de la DRAM, avant qu’une variante plus fine ne la dépasse à son tour.

Les GPU sont longtemps restés à l’écart de cette course. Leur mémoire (GDDR, puis HBM) semblait moins exposée, et l’ECC — qu’il soit SECDED ou on-die — a été présenté comme la barrière définitive. C’est précisément cette hypothèse que GPUThor fait tomber : l’ECC corrige les erreurs à bit unique, mais se comporte mal face aux erreurs multi-bits que le martèlement finit par provoquer.

Le déplacement de la menace vers le GPU n’a rien d’un hasard. Le GPU est devenu la ressource la plus mutualisée des infrastructures modernes : cloud GPU, clusters d’entraînement, inférence partagée. Là où le CPU d’un serveur est rarement loué à un tiers, une carte GPU l’est couramment. C’est exactement le terrain dont Rowhammer a besoin : un co-locataire qui exécute du code non maîtrisé sur la même mémoire que vous.

Ce que cela implique pour les opérateurs

L’enjeu dépasse le laboratoire. Les GPU partagés sont la norme dans le cloud et les clusters d’IA : plusieurs locataires, plusieurs jobs, une seule carte. Si un job CUDA non maîtrisé peut flipper des bits dans la mémoire d’un voisin, la frontière d’isolation entre charges de travail ne tient plus au niveau matériel. Un attaquant qui loue une tranche de GPU dans un environnement mutualisé, ou qui fait exécuter du code non audité sur votre cluster interne, dispose d’un vecteur vers le root de l’hôte.

Les défenses recommandées par les chercheurs sont pragmatiques : éviter le partage multi-locataire du GPU quand c’est possible, surveiller les compteurs d’erreurs ECC, et restreindre l’exécution de CUDA non maîtrisé. Concrètement, cela revient à traiter le GPU comme une frontière de confiance, au même titre qu’un hyperviseur : on n’y exécute pas du code tiers sans isolation et sans télémétrie.

La surveillance des compteurs ECC est la mesure la plus immédiate à déployer, car une attaque en cours laisse des traces lisibles avant la panne ou la compromission :

# Compter les erreurs ECC corrigées et non corrigées sur un GPU NVIDIA
nvidia-smi --query-gpu=ecc.errors.corrected.volatile.total,ecc.errors.uncorrected.volatile.total \
  --format=csv,noheader

Un pic d’erreurs non corrigées, ou une progression anormale des erreurs corrigées, n’est pas un artefact anodin : c’est le signal précoce d’un martèlement en cours.

Verdict

Si vous exploitez un cluster GPU mutualisé ou un cloud GPU multi-locataires, traitez GPUThor comme un changement de frontière : activez SYS-ECC et l’isolation IOMMU/DMA, branchez la télémétrie d’erreurs sur votre supervision, et refusez l’exécution de CUDA non audité sur les nœuds partagés. Le coût d’un flip de bit exploité n’est plus un déni de service — c’est un shell root sur l’hôte.

Si vous n’exécutez que vos propres charges sur des GPU dédiés, le risque principal devient le DoS et la corruption de données d’entraînement, pas l’escalade : isolez les nœuds sensibles, épinglez les modèles critiques et surveillez les compteurs ECC avant de conclure que vous êtes indemne. L’ECC n’est plus une assurance ; c’est un témoin lumineux qu’il faut regarder.

Références

• New GPUThor attack defeats NVIDIA ECC protection for root access — BleepingComputer, 26 août 2026
• GPUThor Rowhammer Defeats ECC on NVIDIA RTX A6000 to Gain Host Root Access — The Hacker News, 27 août 2026
• GPUThor paper — University of Toronto, publié le 25 août 2026