La vulnérabilité historique Rowhammer revient sur le devant de la scène avec de nouvelles avancées préoccupantes. Deux équipes de recherche indépendantes ont démontré que certaines GPU NVIDIA équipées de mémoire GDDR6 peuvent être exploitées comme point d’entrée pour compromettre non seulement la mémoire de la carte graphique, mais aussi la mémoire principale du système hôte. Les travaux, regroupés sous les noms GDDRHammer et GeForge, soutiennent qu’un utilisateur sans privilèges, en exécutant du code sur la GPU, pourrait obtenir des accès en lecture et écriture arbitraires à la mémoire de la CPU, aboutissant à un contrôle complet de la machine.

Ce qui est frappant ici, ce n’est pas seulement que la vulnérabilité Rowhammer ait survécu plus d’une décennie depuis sa découverte dans la DRAM classique, mais qu’elle s’étende désormais au domaine graphique. Le site technique de référence des chercheurs, gddr.fail, affirme que ces équipes ont réussi à corrompre des tables de pages GPU via des bit-flips en GDDR6, ouvrant la voie à un accès à la mémoire de l’hôte. NVIDIA, de son côté, avait déjà publié en juillet 2025 une note de sécurité reconnaissant le risque de Rowhammer sur certains produits équipés de configurations mémoire spécifiques, rappelant notamment des mitigations telles que l’ECC à l’échelle du système.

D’un problème de fiabilité à une voie d’escalade totale

Selon la divulgation publique de GDDRHammer, l’attaque exploite de nouveaux schémas de hammering et techniques pour contourner les protections internes du dispositif, obtenant ainsi un nombre de bit-flips bien supérieur à celui observé dans les études précédentes sur GPU. Les chercheurs ont caractérisé 25 GPU GDDR6, incluant des modèles professionnels de familles telles qu’Ampere et Ada, et décrivent une faille dans l’allocateur de mémoire par défaut (cudaMalloc) qui permettrait de briser l’isolation entre les tables de pages et les données utilisateur à l’intérieur de la GPU. En modifiant la traduction des adresses, un attaquant pourrait utiliser la GPU pour lire et écrire dans toute la mémoire de la CPU.

GeForge arrive également à une conclusion similaire par une approche technique différente. Son résumé indique que l’attaque corrompt les traductions des tables de pages GPU via des bit-flips en GDDR6 et, lorsque IOMMU est désactivé, peut étendre cet accès arbitraire à la mémoire de l’hôte, allant jusqu’à ouvrir une shell avec des privilèges root. Le site des chercheurs présente une démonstration d’exploitation et insiste sur le fait que l’objectif n’est pas simplement de perturber un réseau neuronal ou de dégrader un calcul, mais de briser directement la frontière entre GPU et CPU.

Une troisième piste de recherche, GPUBreach, a été relayée publiquement par Ars Technica. Elle propose une approche différente : combiner Rowhammer sur la GPU avec des failles de sécurité dans le pilote NVIDIA pour escalader les privilèges même lorsque IOMMU activé. Comme cette dernière étude n’est pas encore détaillée dans le site technique gddr.fail accessible au public, il convient de l’aborder avec prudence, la considérant comme une extension supplémentaire reportée par Ars, et non comme une composante du même travail technique principal.

Quelles cartes sont confirmées comme vulnérables ?

Il faut distinguer ce qui a été démontré de ce qui reste hypothétique. Le site gddr.fail et les analyses techniques concordent pour désigner comme victimes identifiées la GeForce RTX 3060 ainsi que des GPU professionnels et stations de travail de la série RTX 6000 / RTX A6000 équipés de GDDR6, notamment dans leur génération Ampere. La note de sécurité de NVIDIA de 2025 citait explicitement une attaque contre une NVIDIA A6000 avec mémoire GDDR6 et expliquait que des mitigations, comme l’activation du System-Level ECC, avaient permis de réduire la vulnérabilité.

En revanche, aucune preuve publique n’atteste que l’ensemble des GPU NVIDIA récents soient également vulnérables. La page de gddr.fail indique qu’ils pensent que tout système doté d’une GPU moderne avec GDDR6 pourrait être susceptible, mais cela ne constitue pas une liste exhaustive confirmée. Ils précisent aussi que, pour l’instant, les modèles A100 avec HBM2 et H100 avec HBM3 n’ont pas montré de vulnérabilités lors de leurs tests, probablement parce que le ECC intégré en circuit masque ces flips de bits, même si les chercheurs ne ferment pas la porte à des scénarios plus agressifs à l’avenir.

NVIDIA ajoute un point important : les générations de mémoire comme DDR4, LPDDR5, HBM3 et GDDR7 intègrent un On-Die ECC qui apporte une protection indirecte contre Rowhammer. La liste officielle du constructeur inclut notamment les GeForce RTX 50 series avec GDDR7, ce qui limite la diffusion de cette alerte à ces composants. En conséquence, à ce jour, le cœur du problème concerne principalement des configurations utilisant GDDR6, et non uniquement GDDR6X, GDDR7 ou HBM dans un sens général.

Mitigations : ECC et IOMMU, mais avec des limites

Les deux principaux contre-mesures évoquées sont l’activation de l’ECC système sur la GPU et le enregistrement de l’IOMMU dans le BIOS ou la configuration du système hôte. La FAQ de gddr.fail recommande l’ECC comme solution temporaire, tout en rappelant qu’elle réduit la mémoire disponible et peut entraîner une surcharge de performance. NVIDIA partage ce point de vue et considère que le System-Level ECC est une défense essentielle pour limiter ou empêcher l’exploitation.

Concernant l’IOMMU, les chercheurs de GDDRHammer et GeForge le présentent comme une protection efficace pour limiter l’étendue des accès de la GPU à la mémoire de l’hôte. Cependant, Ars indique qu’une troisième étude, GPUBreach, aurait trouvé un vecteur permettant même avec IOMMU activé de réaliser une escalade de privilèges, en exploitant aussi des erreurs au niveau du driver. Ceci souligne que l’IOMMU reste fortement recommandé, mais ne doit pas être considéré comme une barrière infranchissable face à toutes les futures variantes.

En résumé, il ne s’agit pas de céder à la panique immédiate, mais de prendre conscience que les GPU partagés, en stations de travail ou en cloud, avec des accélérateurs réutilisés par plusieurs utilisateurs, présentent désormais un risque supplémentaire. Surtout, les remèdes classiques contre Rowhammer ne peuvent plus s’en remettre uniquement à la CPU. Les auteurs de GDDRHammer insistent sur le fait que toute stratégie robuste de mitigation doit également prendre en compte la mémoire graphique.

Questions fréquentes

Quelles GPU NVIDIA sont confirmées comme vulnérables par ces attaques ?
Les démonstrations publiques concernent principalement la GeForce RTX 3060 et des modèles professionnels ou station de travail tels que la RTX 6000 / RTX A6000 équipés de GDDR6, notamment dans la génération Ampere. La recherche laisse penser que d’autres GPU avec GDDR6 pourraient l’être aussi, mais aucune liste officielle exhaustive n’a été publiée.

Ce problème concerne-t-il aussi les GPU avec GDDR7 ou HBM ?
Avec les données publiques disponibles à ce jour, aucune preuve n’indique que ce soit le cas. NVIDIA mentionne que GDDR7 et autres mémoires modernes embarquent un On-Die ECC, et les analyses des chercheurs montrent que l’A100 (HBM2) et la H100 (HBM3) ne présentent pas de vulnérabilités dans leurs tests actuels.

Activer IOMMU résout-il le problème ?
Il réduit clairement le risque pour les mécanismes d’exploitation exploitant GDDRHammer et GeForge, car il limite l’accès de la GPU à la mémoire de l’hôte. Mais Ars signale qu’une troisième approche, GPUBreach, aurait permis d’escalader les privilèges même avec IOMMU activé en exploitant des failles dans le pilote. L’IOMMU reste donc une précaution recommandée mais pas une solution infaillible.

Activer ECC sur la GPU est-il judicieux ?
Oui, c’est une des protections les plus recommandées, tant par NVIDIA que par les chercheurs. Cependant, cela a un coût : réduction de la mémoire utilisable et impact potentiel sur les performances. Par ailleurs, la FAQ de gddr.fail rappelle que dans certains contextes, des attaques Rowhammer passées ont réussi à contourner ces protections ECC, argumentant qu’aucune solution n’est totalement infaillible.

Sources : Ars Technica, videocardz et Gddr.fail