Researchers at the University of Toronto have published GPUThor, a Rowhammer variant that does what no prior GPU memory-corruption attack has managed: it defeats error-correcting code (ECC) on NVIDIA GDDR6 GPUs, the exact mitigation vendors and researchers — including this outlet’s coverage of April’s GPUBreach disclosure — recommended as the stopgap fix. No CVE has been assigned and no in-the-wild exploitation has been reported, but the technique closes a mitigation gap that infrastructure teams have been leaning on for four months.

What’s new

Rowhammer works by rapidly and repeatedly activating (“hammering”) a DRAM row to induce bit-flips in physically adjacent rows. GPUThor’s contribution is non-uniform hammering: rather than hammering the aggressor row and decoy rows at a uniform rate to swamp GDDR6’s Target Row Refresh (TRR) defense, it activates the aggressor row far more often than the decoys, accounting for two previously undocumented GPU behaviors — how the memory controller coalesces repeated requests, and how frequently TRR actually fires. That tuning produces roughly 6.6x more effective aggressor-row activations than prior approaches (including 2025’s GPUHammer), yielding 72,000–377,000 bit flips per GB on unprotected cards and cutting the time to find an exploitable flip from GPUHammer’s 21.9 hours down to about 1.1 minutes.

Against ECC-enabled cards, sustained hammering produced 387 double-bit errors — which ECC can detect but not correct — and two triple-bit errors, which ECC “corrected” incorrectly, silently corrupting data instead of halting safely. That combination is sufficient to drive the same page-table-corruption chain GPUBreach demonstrated in April, escalating from an unprivileged CUDA kernel to a root shell on the host, ECC notwithstanding.

Who’s affected

Tested and confirmed vulnerable: NVIDIA Ampere-generation workstation GPUs with GDDR6 — RTX A4000, A4500, A5000, and A6000. These are common in on-prem ML workstations, render farms, and GPU-passthrough VMs, and they’re precisely the cards infrastructure teams were told to run in ECC mode as the fix for GPUBreach. Datacenter GPUs using HBM (A100, H100, H200, B100/B200) remain out of scope — HBM’s on-die ECC architecture is structurally different from GDDR6’s and isn’t affected by this technique.

The risk concentrates wherever untrusted code can submit CUDA kernels on shared hardware: multi-tenant Kubernetes GPU scheduling, CI/CD runners with GPU access for model training or compilation, and any environment where one tenant’s workload sits on the same physical card as another’s.

Mitigation

There is no software fix for the underlying DRAM physics, and NVIDIA has not shipped a driver patch. NVIDIA’s updated guidance, issued after the GPUThor report, recommends:

  • Enable both SYS-ECC and host IOMMU/DMA isolation — neither alone is sufficient anymore.
  • Monitor ECC error telemetry continuously via nvidia-smi --query-gpu=ecc.errors.corrected,ecc.errors.uncorrected --format=csv or DCGM; a rising double-bit error count is now a leading indicator of an active attack, not background noise.
  • Restrict GPU sharing to vetted, trusted workloads until further notice — MIG partitioning on datacenter cards remains unaffected, but RTX/RTX-A time-slicing does not provide isolation against this class of attack.
  • Where the threat model includes untrusted CUDA workloads on shared infrastructure, prefer HBM-based datacenter GPUs (A100/H100 and later) over GDDR6 workstation cards.

Consumer GeForce cards were already unprotected (no ECC support at all) and remain so; this disclosure primarily changes the risk calculus for the workstation-tier cards teams moved to specifically for Rowhammer resistance.

References