Une nouvelle étude académique met en lumière une variante de Rowhammer baptisée GPUThor Rowhammer. Les chercheurs expliquent que leur approche parvient à provoquer des bit flips sur des GPU de poste de travail NVIDIA utilisant de la mémoire GDDR6, en particulier lorsque l’ECC n’est pas configuré comme attendu. Plus inquiétant encore : les résultats décrivent aussi des voies d’attaque pouvant mener à des perturbations de service (DoS) et à une escalade de privilèges jusqu’à un accès root côté hôte.
Dans ce qui suit, nous résumons ce que les auteurs rapportent sur le mécanisme technique, les cartes concernées, et surtout les implications pratiques pour la sécurité des environnements où des charges GPU non fiables peuvent s’exécuter.
De quoi parle l’attaque GPUThor Rowhammer ?
Le principe de Rowhammer repose sur la possibilité de forcer des activations répétées dans des cellules mémoire adjacentes afin de déclencher des fautes matérielles. Avec GPUThor Rowhammer, l’idée centrale est d’exploiter une stratégie de “frappe” non uniforme : certaines lignes mémoire dites “agresseurs” sont activées bien plus souvent que des lignes “leurres” censées saturer les mécanismes de défense.
Les chercheurs indiquent que les attaques précédentes activaient globalement agresseurs et leurres à un rythme comparable. Au contraire, GPUThor met en place un profil où la ligne victime est compromise plus efficacement, ce qui augmente la probabilité d’erreurs exploitables.
Sur quels GPU les chercheurs observent une vulnérabilité
La campagne d’évaluation a été menée sur des cartes Ampere de NVIDIA équipées de GDDR6. Les auteurs rapportent avoir testé plusieurs modèles, tous classés comme vulnérables dans leur périmètre :
- RTX A6000 (48 Go, GDDR6)
- RTX A5000 (24 Go, GDDR6)
- RTX A4500 (20 Go, GDDR6)
- RTX A4000 (16 Go, GDDR6)
D’après leurs mesures, les campagnes ont généré, lorsque l’ECC est désactivé, des volumes importants de bit flips par gigaoctet — avec un cas particulièrement marquant : la RTX A5000 affiche la plus forte sensibilité observée.
Pourquoi la défense ECC ne suffit pas dans certains scénarios
Les auteurs rappellent que ces GPU utilisent une forme d’ECC de type SECDED (capable de corriger une erreur simple et de détecter deux erreurs dans un bloc protégé). Leur analyse suggère toutefois que l’ECC peut mal corriger certaines fautes multi-bits, ce qui mène à de la corruption silencieuse de données (SDC).
En pratique, les chercheurs décrivent deux effets lorsque l’ECC est activé :
- Des erreurs détectées mais non corrigeables (DUE) qui entraînent l’arrêt de tous les kernels en cours, rendant la carte inutilisable jusqu’à un redémarrage.
- Des scénarios de SDC qui peuvent ne pas déclencher d’alerte immédiate, laissant une fenêtre d’exploitation.
Ils indiquent notamment qu’au cours d’une journée d’observation sur une RTX A6000 configurée localement avec ECC, une fréquence moyenne d’environ une DUE toutes les deux heures a été observée sur leur configuration de test, avec aussi un événement de SDC.
Le point clé : une frappe basée sur la topologie interne
Les chercheurs détaillent une subtilité qui, selon eux, améliore l’efficacité de GPUThor Rowhammer. Ils décrivent la façon dont les accès mémoire sont regroupés au niveau du contrôleur mémoire.
Plus précisément, lorsque des accès sont émis à l’intérieur d’un même warp (un groupe de 32 threads exécutés de manière synchronisée), le contrôleur mémoire les fusionne en une activation DRAM unique. En revanche, des accès provenant de warps différents, visant des lignes de cache distinctes dans la même ligne mémoire, peuvent être conservés comme des activations séparées.
Autrement dit, la stratégie de noyau (kernel) répartit la frappe pour maximiser les conditions qui mènent à des erreurs tout en contournant certaines protections liées au comportement de rafraîchissement.
Conditions d’attaque : lancement d’un kernel CUDA non privilégié
Pour mettre en œuvre l’attaque, les auteurs précisent qu’il faut pouvoir lancer un kernel CUDA non privilégié sur le GPU visé. Cela peut se produire dans des environnements où l’agresseur partage le matériel avec un autre locataire (“co-tenant”), ou bien quand l’attaquant exécute du code non fiable sur une machine dédiée.
Ils recommandent, pour réduire le risque :
- De limiter le partage GPU entre locataires lorsque c’est possible.
- De surveiller les compteurs d’erreurs ECC.
- De restreindre l’exécution de workloads CUDA non approuvés.
De la mémoire corrompue à l’escalade côté hôte
Au-delà de la démonstration de bit flips, l’étude décrit une chaîne menant à une escalade de privilèges. Les chercheurs indiquent avoir réutilisé du code exploit provenant de travaux antérieurs autour de l’escalade de privilèges basée sur la table des pages GPU.
Le schéma général, tel que rapporté, consiste à :
- Modifier d’abord des structures de pages de manière à atteindre une configuration vulnérable.
- Frapper les zones mémoire voisines pour corrompre un champ critique, notamment le numéro de cadre de page (page-frame number).
- Exécuter un second kernel qui permet alors d’accéder à une zone mémoire en dehors du processus visé.
Le résultat final dépend des types d’erreurs obtenues. Les auteurs rapportent que l’exploitation fondée sur une SDC à trois bits permet d’obtenir un accès root côté hôte lorsque l’IOMMU est activé. À l’inverse, une escalade basée sur une DUE à deux bits fonctionnerait lorsque l’IOMMU est désactivé, en orientant l’entrée de table vers la mémoire CPU.
Ils ajoutent un élément temporel important : selon leur explication, les DUE seraient traitées de façon “paresseuse” sur ces GPU, ce qui créerait une fenêtre d’environ ~10 ms entre la détection et la mise à mort du GPU. Durant ce laps de temps, les données corrompues peuvent être consommées par le kernel de l’attaquant.
Ordres de grandeur : recherche et exécution
Les auteurs indiquent qu’identifier des erreurs multi-bits exploitables sans déclencher immédiatement une DUE peut prendre plusieurs jours. Sur une RTX A6000, la localisation prendrait environ quatre jours dans leurs conditions.
Ensuite, ils rapportent des temps d’attaque de bout en bout : par exemple, une escalade de privilèges décrite comme aboutissant en 1,1 minute avec des motifs de type GPUHammer, et 1,1 minute également avec des motifs GPUThor sur leur carte de test, après la phase de préparation.
Qu’en est-il des autres générations et types de mémoire ?
Les chercheurs indiquent avoir testé d’autres configurations mémoire et d’autres GPU, et n’avoir pas observé de bit flips avec les patterns GPUThor. Ils mentionnent notamment :
- Des GPU comme A10, L4, L40 (en GDDR6),
- Une RTX 4090 (GDDR6X),
- Une A30 (HBM2e).
Ils expliquent que des différences dans les implémentations de TRR (Target Row Refresh) pourraient rendre la stratégie de GPUThor Rowhammer inefficace sur ces autres cartes et types de mémoire.
Concernant A100 et H100, ils précisent qu’elles ne faisaient pas partie de l’ensemble de modèles testés dans l’étude.
Ce que disent les auteurs sur l’avenir des protections
Enfin, l’article met en avant que des générations serveur (selon la description des auteurs) incluent des mécanismes comme la confinement d’erreur et l’offlining de pages. Toutefois, les chercheurs suggèrent que des escalades basées sur corruption silencieuse pourraient encore être envisageables contre des systèmes reposant sur une ECC de niveau SECDED.
Ils indiquent aussi qu’un correctif complet demanderait des protections matérielles plus robustes, y compris une meilleure correction des erreurs multi-bits et des défenses plus fines au sein même de l’architecture mémoire (par exemple, des mécanismes liés au comptage d’activation par rangée ou à la gestion de rafraîchissement).
Publication, absence de correctif et état des connaissances
Selon les informations rapportées, les chercheurs ont notifié NVIDIA le 29 avril 2026, ainsi que Google, Microsoft et AWS. Une période d’embargo aurait ensuite encadré la divulgation jusqu’au 25 août 2026.
À la date de publication de l’article source, GPUThor ne possède pas d’identifiant CVE, et aucune exploitation “dans la nature” n’aurait été signalée. Les auteurs affirment également qu’aucun correctif n’est annoncé, et que les travaux publics sont prévus pour le 15 novembre 2026 (jour d’ouverture de la conférence ACM sur la sécurité des communications et des ordinateurs).
Conclusion : activer l’ECC, mais revoir la stratégie de risque
Le message de l’étude est clair : la capacité de l’ECC à augmenter l’effort nécessaire à l’attaquant reste réelle. Cependant, GPUThor Rowhammer montre que, dans certains contextes et sur certains modèles, l’ECC ne doit plus être considérée comme une protection suffisante à elle seule.
Pour les organisations qui exécutent des charges GPU non fiables, la prudence consiste à réduire la surface d’attaque (notamment en évitant le partage entre locataires), à surveiller systématiquement les indicateurs d’erreurs ECC, et à appliquer des restrictions sur les workloads CUDA. À plus long terme, les résultats plaident pour des défenses matérielles capables de mieux gérer les erreurs multi-bits et de renforcer la protection au niveau des mécanismes mémoire internes.
Source: https://thehackernews.com/2026/08/gputhor-rowhammer-defeats-ecc-on-nvidia.html
