GPUThor : une attaque Rowhammer contourne l'ECC des GPU Nvidia

Des chercheurs de l'Université de Toronto ont dévoilé fin août une nouvelle technique d'attaque baptisée « GPUThor », capable de contourner la protection ECC (correction d'erreur mémoire) intégrée aux GPU Nvidia. La méthode, fondée sur le principe du Rowhammer, a été validée sur des GPU de station de travail d'architecture Ampere équipés de mémoire GDDR6 — les RTX A4000, A4500, A5000 et A6000 —, des modèles largement utilisés dans les infrastructures d'IA et de cloud. L'équipe a signalé la faille à Nvidia dès le 29 avril, et l'entreprise a publié ses recommandations de mitigation le 25 août, après une période de divulgation coordonnée d'environ quatre mois.

Pourquoi l'ECC est indispensable sur un GPU d'IA

Une puce mémoire soumise à une charge intense peut, de façon aléatoire, subir une « inversion de bit » (bit flip) : un bit stocké à 0 bascule accidentellement à 1, ou inversement, sous l'effet de rayons cosmiques, d'interférences électriques ou de défauts de fabrication. Pour un usage grand public, une inversion isolée passe souvent inaperçue. Mais pour l'entraînement ou l'inférence d'un modèle d'IA, elle peut altérer directement des poids, des gradients ou des valeurs d'activation — faussant silencieusement un entraînement ou produisant, en inférence, une réponse erronée mais plausible, sans le moindre signal d'alerte. C'est précisément le rôle de l'ECC : en stockant un code de contrôle supplémentaire pour chaque bloc mémoire, le système corrige automatiquement les erreurs sur un seul bit et détecte celles sur deux bits (norme SECDED). C'est cette garantie qui permet aux fournisseurs cloud de faire cohabiter plusieurs clients sur une même carte GPU physique en toute confiance.

Comment GPUThor déjoue la protection ECC

GPUThor repose sur un rythme de sollicitation mémoire volontairement non uniforme, combiné à l'exploitation de deux comportements du GPU que Nvidia n'avait jamais documentés : la manière dont les requêtes mémoire répétées sont regroupées (coalescence), et la fréquence réelle de déclenchement du mécanisme Target Row Refresh (TRR) de la mémoire GDDR6, censé prévenir ce type d'attaque. En restant sous le seuil de détection du TRR, GPUThor peut « marteler » en continu la rangée mémoire ciblée, provoquant des inversions de bits dans les rangées voisines.

• Sur les GPU testés sans ECC activé, GPUThor provoque entre 72 000 et 377 000 inversions de bit par gigaoctet de mémoire — jusqu'à 23 597 fois plus que la précédente attaque de l'équipe, GPUHammer.
• Même avec l'ECC activé, GPUThor génère 387 erreurs à deux bits (détectées mais non corrigibles par l'ECC) et deux erreurs à trois bits, que l'ECC corrige mal, provoquant une corruption de données.
• Le temps nécessaire pour trouver une inversion de bit exploitable tombe à environ 1,1 minute, contre 21,9 heures avec GPUHammer.
• Une attaque soutenue sur une RTX A6000 avec ECC activé peut forcer le GPU à se réinitialiser toutes les deux heures, interrompant toutes les tâches en cours ; répétée, elle peut amener la carte à se signaler elle-même comme devant être remplacée.

Au-delà du déni de service, les chercheurs ont démontré un scénario plus grave : en corrompant les tables de pages du GPU, un programme CUDA sans privilège particulier peut obtenir un accès mémoire arbitraire et ouvrir un shell root sur la machine hôte — une simple tâche de calcul GPU peut ainsi déboucher sur une prise de contrôle totale du serveur. Les GPU de data center de génération Ampere, comme le A100, résistent mieux au déni de service mais restent exposés à l'escalade de privilèges ; même les GPU Blackwell dotés de la protection RAS Repair ne font que ralentir l'attaque sans l'empêcher. Les chercheurs avertissent que les futurs GPU en GDDR7 ou HBM3e, dotés d'ECC intégré à la puce mémoire elle-même, pourraient rester vulnérables dans des scénarios d'inversions multi-bits.

Qui est réellement exposé

GPUThor vise les grappes de GPU des centres de données dédiées à l'entraînement et à l'inférence IA, et tout particulièrement les instances cloud GPU multi-locataires — le modèle de fonctionnement par défaut de la plupart des offres GPU dans le cloud public, où plusieurs clients se partagent une même carte physique. Un attaquant capable de louer un simple créneau de calcul pourrait ainsi perturber, voire corrompre, l'entraînement ou l'inférence d'un autre client hébergé sur la même machine — un risque invisible depuis la couche applicative. Les recommandations de Nvidia portent sur l'isolation et la surveillance : activer SYS-ECC et l'isolation IOMMU/DMA, surveiller en continu la télémétrie des erreurs GPU, et limiter le partage de charges CUDA non fiables sur un même matériel.

Ce que ça change pour les entreprises françaises

La France héberge une offre cloud GPU en propre — OVHcloud, Scaleway et plusieurs opérateurs de data centers proposent des instances GPU Nvidia partagées, souvent mises en avant comme alternative souveraine aux hyperscalers américains. GPUThor ne remet pas en cause ce positionnement, mais il rappelle qu'une offre « souveraine » ne vaut que par ses pratiques d'isolation réelles : les opérateurs français qui louent des GPU Nvidia à plusieurs clients devraient vérifier sans attendre l'activation de SYS-ECC et de l'isolation IOMMU/DMA recommandée par Nvidia, mettre en place une surveillance continue de la télémétrie d'erreurs mémoire, et traiter le risque d'isolation entre locataires GPU comme un sujet d'audit de sécurité à part entière — au même titre que la conformité RGPD sur l'intégrité des données traitées — plutôt que comme une simple ligne de spécification technique parmi d'autres.