GDDRHammer et GeForge : des chercheurs prouvent qu'une carte graphique Nvidia en GDDR6 peut servir de rampe de lancement
pour prendre le contrôle total d'une machine, sans aucun privilège ni authentification
Deux équipes de chercheurs indépendantes ont publié le 2 avril 2026 des travaux qui redéfinissent la surface d'attaque des processeurs graphiques modernes. Baptisées GeForge et GDDRHammer, ces nouvelles variantes de l'attaque Rowhammer ciblent la mémoire GDDR6 des cartes Nvidia et parviennent, depuis un simple noyau CUDA non privilégié, à corrompre les tables de pages du GPU pour ensuite lire et écrire librement dans la RAM du processeur central et ouvrir un shell root. Le tout sans authentification.
Rowhammer est une de ces vulnérabilités matérielles que l'industrie a longtemps préféré classer dans la catégorie « connue mais peu pratique ». Découverte en 2014, elle repose sur un phénomène physique inhérent à la conception des puces DRAM : en accédant de façon répétée et rapide à une rangée de cellules mémoire, on génère des interférences électromagnétiques qui peuvent faire basculer des bits dans les rangées adjacentes (un 0 devient 1, ou vice versa). Ce mécanisme est connu depuis des années dans le contexte de la RAM des CPU, où il a progressivement évolué pour cibler des types de mémoire de plus en plus récents, du DDR3 jusqu'au DDR5.
Mais jusqu'à l'an dernier, les GPU semblaient épargnés. C'était sans compter sur GPUHammer, travail pionnier de l'Université de Toronto publié en juillet 2025, qui a démontré pour la première fois en pratique que Rowhammer fonctionne également sur les GPU Nvidia équipés de mémoire GDDR6. L'accent était alors mis sur la détection fiable des basculements de bits dans la VRAM et sur leur impact sur les modèles d'IA, notamment une dégradation de la précision de classification. Nvidia avait répondu par un avis de sécurité et pointé vers l'activation de l'ECC comme contre-mesure. Un premier signal d'alarme, auquel l'industrie n'a pas encore vraiment répondu.
Deux nouvelles attaques viennent de franchir un palier bien plus inquiétant.
GDDRHammer : 64 fois plus de basculements, une chaîne d'exploitation complète
Le 2 avril 2026, deux équipes de recherche indépendantes ont divulgué des attaques qui font escalader les basculements de bits en mémoire GDDR6 jusqu'à l'obtention d'un shell root sur la machine hôte depuis un noyau CUDA non privilégié, sans authentification.
La première, GDDRHammer, est le fruit d'une collaboration entre l'Université de Caroline du Nord à Chapel Hill, Georgia Tech et le Mohamed bin Zayed University of AI. Les chercheurs ont caractérisé 25 GPU GDDR6 différents, développé de nouvelles techniques pour contourner les mécanismes de mitigation Rowhammer intégrés aux appareils, et mis au point un martelage double face exploitant le parallélisme massif du GPU. Résultat : en moyenne 64 fois plus de basculements de bits que ce que les travaux précédents avaient réussi à obtenir.
La technique clé s'appelle le « memory massaging », ou façonnage mémoire. GDDRHammer affirme avoir obtenu en moyenne environ 129 basculements par banque DRAM dans son cadre expérimental, et démontre un exploit de bout en bout où un noyau CUDA non privilégié finit par lire et écrire toute la mémoire CPU de la machine. Concrètement, l'attaque pousse les structures de données ciblées (les tables de pages du GPU) vers des régions mémoire non protégées par les pilotes graphiques contre ce type de perturbation électrique. Une fois ces tables corrompues, l'isolation mémoire est brisée : le GPU peut être redirigé pour accéder à n'importe quelle adresse physique, y compris dans la RAM du CPU.
GeForge : un cran plus loin dans la chaîne d'exploitation
La seconde attaque, GeForge, a été développée indépendamment par des équipes de Purdue University, University of Rochester, University of Western Australia, Clemson et HydroX AI. Elle emprunte un vecteur légèrement différent mais aboutit au même résultat dévastateur.
Là où GDDRHammer exploite les tables de pages de dernier niveau (PT), GeForge cible le répertoire de pages de dernier niveau (PD0) (la structure qui pointe vers ces tables). En corrompant les traductions de tables de pages GPU via des basculements en GDDR6, l'attaque obtient un accès arbitraire à l'espace mémoire du GPU, puis à la mémoire hôte.
Les chercheurs ont réussi à induire 1 171 basculements de bits sur un RTX 3060 et 202 sur un RTX A6000. Cela permet à un attaquant de modifier la table de pages du GPU pour qu'elle pointe vers la mémoire du CPU, lui donnant ainsi la capacité de lire et d'écrire l'intégralité de la mémoire du processeur central, ce qui compromet totalement la machine.
Les auteurs de GeForge décrivent plusieurs innovations techniques pour y parvenir : une stratégie de façonnage mémoire qui oriente les tables de pages du GPU vers des bits vulnérables, un motif de martelage non uniforme produisant davantage de basculements, et une technique d'ancrage de pages permettant de localiser les adresses physiques GPU à l'exécution.
GPUBreach : le troisième larron qui contourne même l'IOMMU
Simultanément à ces deux travaux, l'équipe de l'Université de Toronto, à l'origine de GPUHammer, a présenté une troisième attaque baptisée GPUBreach, qui mérite d'être mentionnée car elle change encore la donne. Là où GeForge requiert que l'IOMMU soit désactivé pour accéder à la mémoire CPU arbitraire, GPUBreach parvient à une escalade de privilèges complète jusqu'au shell root même avec l'IOMMU activé, en exploitant des vulnérabilités de sécurité mémoire dans le pilote Nvidia lui-même plutôt qu'en contournant directement l'IOMMU. Cette distinction est capitale pour l'évaluation du risque réel.
Quelles cartes sont vulnérables, et pourquoi la GDDR6 ?
Seule la mémoire GDDR6 semble affectée par ces attaques Rowhammer pour l'instant. Les équipes ont testé 25 GPU équipés de cette technologie et trouvé des vulnérabilités sur la majorité d'entre eux. Les cartes plus récentes dotées de GDDR6X ou GDDR7 ont également été testées, mais n'ont pas pu être compromises.
Les tests sur RTX 3080, RTX 4060, RTX 4060 Ti et RTX 5050 n'ont pas révélé de basculements de bits induits sur ces cartes. Le papier GDDRHammer ne rapporte par ailleurs aucun basculement induit sur les GPU Ada RTX 6000 testés et suggère que la GDDR6X bénéficie de protections plus robustes que la GDDR6. Nvidia indique par ailleurs que ses appareils GDDR7, dont la gamme RTX 50, implémentent un ECC on-die qui contribue indirectement à la protection contre Rowhammer.
La concentration de GPU Ampere (RTX 30xx, A6000) dans les parcs de calcul cloud représente donc le périmètre de risque immédiat le plus significatif.
Un risque particulièrement aigu pour les infrastructures cloud GPU
Si l'attaque requiert un accès préalable au système pour exécuter du code, ce qui la distingue des attaques réseau à distance, le profil de menace change radicalement dans le contexte du cloud GPU. Les attaques ne nécessitent que l'accès standard à l'exécution CUDA, c'est-à-dire le niveau d'accès que reçoivent les locataires GPU dans le cloud. Le partage de GPU par tranches de temps (time-slicing), le mode de partage par défaut utilisé par de nombreux fournisseurs cloud, offre des fenêtres temporelles suffisantes pour mener l'attaque Rowhammer.
Autrement dit, dans un environnement où plusieurs clients partagent le même GPU physique, scénario courant dans les offres cloud de calcul IA, un locataire malveillant pourrait théoriquement compromettre les données et les processus des autres. SR-IOV crée des fonctions virtuelles matérielles avec protection IOMMU par VM, bloquant l'escalade GPU-vers-CPU. En revanche, il ne prévient pas les attaques Rowhammer intra-GPU entre fonctions virtuelles partageant la même mémoire GDDR6 physique.
Les contre-mesures disponibles et leurs limites
Nvidia préconise deux lignes de défense principales.
La première est l'activation de l'ECC (Error Correcting Code), qui permet de détecter et corriger les basculements de bits avant qu'ils ne puissent être exploités. Cette option réduit cependant la capacité totale de VRAM utilisable, introduit une surcharge de performance, et n'est pas disponible sur toutes les cartes. De plus, des travaux antérieurs comme ECCploit et ECC.fail ont déjà montré que des attaques Rowhammer bien conçues peuvent contourner l'ECC via des basculements multi-bits.
La seconde ligne de défense est l'activation de l'IOMMU (Input-Output Memory Management Unit) dans le BIOS. L'IOMMU impose une frontière stricte autour des périphériques non-CPU lorsqu'ils tentent d'accéder à la mémoire système. Normalement, un GPU peut lire ou écrire dans la mémoire système sans solliciter le CPU à chaque fois (via l'accès direct à la mémoire, DMA), c'est précisément par là que GDDRHammer ou GeForge s'infiltrent dans la RAM système. Avec l'IOMMU activé, les tables de pages corrompues avec des mappings incorrects ne peuvent pas être exploitées pour accéder au CPU. Par défaut, l'IOMMU est désactivé dans le BIOS pour éviter des problèmes de compatibilité liés à sa rigueur.
Mais comme l'illustre GPUBreach, l'IOMMU n'est pas non plus une garantie absolue : un attaquant suffisamment sophistiqué peut exploiter des failles dans les pilotes Nvidia pour contourner cette protection. Les recommandations actuelles (ECC activé, IOMMU activé, abandon du time-slicing pour les charges de travail GDDR6 critiques) constituent le minimum de prudence, non un rempart infaillible.
Une trajectoire d'escalade préoccupante
Ce qui frappe dans cette série de publications, c'est moins la découverte isolée d'une faille que la progression systématique de la recherche offensive sur les GPU. La trajectoire est révélatrice : de 8 basculements de bits en 2025 à 1 171 en 2026, d'une dégradation de la précision des modèles d'IA à l'obtention d'un shell root, d'attaques bloquables par IOMMU à des attaques capables de le contourner. C'est un domaine de recherche qui s'accélère encore.
Les trois papiers (GDDRHammer, GeForge et GPUBreach) seront présentés en intégralité au 47e Symposium IEEE sur la Sécurité et la Confidentialité (IEEE S&P 2026), du 18 au 20 mai à San Francisco. Les codes source des exploits sont déjà partiellement disponibles sur le site gddr.fail.
Pour les administrateurs système gérant des parcs de GPU GDDR6, en particulier dans des environnements cloud ou HPC multi-locataires, l'heure n'est plus à la veille mais à l'action : vérification de la configuration IOMMU, activation de l'ECC sur les cartes professionnelles, et révision des politiques de partage GPU.
Sources : GDDR.fail (Page de projet pour les deux articles avec une brève description, une FAQ, une distinction entre GDDRHammer et GeForge, et une référence à l'accès à la mémoire du processeur et à la norme IEEE S&P 2026), GDDRHammer / IEEE S&P 2026 (L'article des chercheurs rapporte une moyenne de 129 basculements de bits par banque de DRAM, un ensemble de test comprenant plus de 25 GPU et 16 des 17 cartes RTX A6000 vulnérables avec GDDR6), GeForge / IEEE S&P 2026 (article des chercheurs décrivant une attaque sur les tables de pages du GPU, plus de 1 100 inversions de bits sur RTX 3060, plus de 200 sur RTX A6000 et une élévation de privilèges au niveau de l'hôte dans les conditions décrites), Nvidia (Avis de sécurité du 9 juillet 2025 concernant Rowhammer sur les GPU NVIDIA, incluant la recommandation et la classification ECC pour les produits professionnels et de centres de données), arXiv / GPUHammer (Thèse de 2025 sur la première démonstration pratique de Rowhammer sur des GPU NVIDIA avec GDDR6)
Et vous ?
Le modèle économique du cloud GPU multi-tenant est-il structurellement incompatible avec un niveau de sécurité acceptable face à ce type d'attaque matérielle et les fournisseurs cloud ont-ils les moyens de migrer rapidement vers des architectures isolées comme MIG (A100/H100) ?
L'ECC on-die implémenté dans les puces GDDR7 des RTX 50 constitue-t-il une défense durable contre les futures variantes de Rowhammer, ou les chercheurs trouveront-ils inévitablement des motifs de martelage capables de provoquer des basculements multi-bits non corrigeables ?
Nvidia porte-t-il une part de responsabilité dans la diffusion lente des contre-mesures, notamment l'IOMMU désactivé par défaut pour des raisons de compatibilité, un compromis qui s'avère aujourd'hui coûteux en termes de sécurité ?








Le modèle économique du cloud GPU multi-tenant est-il structurellement incompatible avec un niveau de sécurité acceptable face à ce type d'attaque matérielle et les fournisseurs cloud ont-ils les moyens de migrer rapidement vers des architectures isolées comme MIG (A100/H100) ?
Répondre avec citation
Partager