Rowhammer attacks — where rapid memory access patterns cause electrical interference that flips bits in adjacent memory rows — have been a known threat to CPU RAM for over a decade. But until now, GPU memory was considered safe. Two new attacks, GeForge and GDDRHammer, have changed that. Researchers demonstrated that they can induce bit flips in Nvidia GPU GDDR6 memory and escalate all the way to root access on the host system.
Both papers will be presented at the 47th IEEE Symposium on Security and Privacy (IEEE S&P 2026), running May 18-20 in San Francisco. A related attack called GPUBreach achieves similar results even with IOMMU protections enabled.
How Rowhammer Works on GPUs
Traditional Rowhammer exploits the physical properties of DRAM: repeatedly reading from one memory row causes electrical interference ("row hammering") that can flip bits in neighboring rows. Defenses like Target Row Refresh (TRR) were added to DDR4 and DDR5 to mitigate this on the CPU side.
GDDR6 memory used in GPUs has different architecture and timing characteristics, and was assumed to be resistant. GDDRHammer proved otherwise. The researchers found that GPU compute shaders can be crafted to repeatedly access specific VRAM addresses, causing bit flips in adjacent rows — with no special hardware or physical access required.
In testing, they observed 1,171 bit flips on an RTX 3060 and 202 flips on an RTX A6000. Most GDDR6-based cards were vulnerable, while newer cards with GDDR6X or GDDR7 memory were not affected in testing.
The Full Attack Chain
The real innovation isn't the bit flips themselves — it's what the researchers did with them. The attack chain achieves full system compromise through four stages:
- GPU memory corruption — Use GDDRHammer to induce targeted bit flips in GPU VRAM
- GPU page table hijacking — GeForge targets GPU page table entries and directories, corrupting the GPU's virtual-to-physical address translation. This gives the attacker arbitrary read/write access to all GPU memory.
- CPU memory access — With GPU page tables under control, the attacker remaps GPU virtual addresses to point at host CPU physical memory. GPU DMA (Direct Memory Access) allows the GPU to read and write CPU memory directly.
- Root shell — With arbitrary CPU memory read/write, the attacker modifies kernel data structures to escalate privileges, achieving root access on the host operating system.
Attack flow summary
Malicious GPU Shader
↓ (GDDRHammer - bit flips in GDDR6)
GPU Page Table Corruption
↓ (GeForge - hijack address translation)
Arbitrary GPU Memory R/W
↓ (remap to host physical addresses via DMA)
CPU Memory R/W
↓ (modify kernel structures)
Root Shell on HostKey distinction: The GPUBreach variant achieves this even with IOMMU (Input/Output Memory Management Unit) enabled. IOMMU is specifically designed to prevent DMA attacks by isolating device memory access — the fact that it can be bypassed makes this attack particularly concerning.
What's Affected
The researchers tested 25 Nvidia GPUs across multiple generations:
- Vulnerable: Most GPUs with GDDR6 memory (GTX 16-series, RTX 20/30/40-series consumer cards, RTX A-series professional cards)
- Not affected in testing: Cards with GDDR6X or GDDR7 memory, which have different internal architecture and timing that made bit flips harder to induce
- AMD GPUs: Not tested in these specific papers, but GDDR6 is GDDR6 regardless of vendor — the physical vulnerability likely exists across manufacturers
Why This Matters for Developers
If you're running GPU workloads in production — machine learning inference, video processing, GPU-accelerated databases — this attack surface is relevant to you. A few implications:
- Cloud GPU instances — Multi-tenant GPU instances (where multiple users share a GPU) could be vulnerable. A malicious tenant running a crafted shader could potentially compromise the host or other tenants. Cloud providers will need to audit their GPU isolation mechanisms.
- WebGPU exposure — WebGPU allows browsers to run GPU compute shaders. While browsers sandbox GPU access heavily, the attack surface exists in theory. Browser vendors will likely add specific mitigations.
- AI inference servers — Servers running untrusted model inference (e.g., user-uploaded models) could be at risk if the model can execute arbitrary GPU operations.
- IOMMU is not sufficient — GPUBreach shows that IOMMU alone doesn't prevent GPU-to-CPU memory attacks. Defense in depth is essential.
Mitigations
There's no simple patch for a hardware vulnerability. The mitigations involve trade-offs:
- GPU driver updates — Nvidia will likely release driver updates that add runtime detection of suspicious memory access patterns, similar to how CPU Rowhammer mitigations work. Expect a performance overhead.
- VRAM access rate limiting — Restricting how rapidly GPU shaders can access adjacent memory rows would reduce the ability to cause bit flips, but at a cost to legitimate compute performance.
- Hardware refresh — GDDR6X and GDDR7 appear resistant. Long-term, hardware rotation to newer memory technology is the most complete mitigation.
- Workload isolation — For cloud providers, ensuring GPU workloads run on dedicated hardware rather than shared instances eliminates the multi-tenant attack vector.
The Bigger Picture
This research is a reminder that GPUs are not just display adapters — they're powerful compute devices with direct memory access to the host system. As GPUs become central to AI inference, scientific computing, and general-purpose acceleration, their security properties matter as much as CPU security. The same scrutiny that Spectre and Meltdown brought to CPU microarchitecture is now arriving for GPU memory.
For now, the practical risk is moderate — exploiting this requires running crafted GPU shaders on the target machine. But as GPU compute becomes more ubiquitous (WebGPU in browsers, GPU cloud instances, AI inference servers), the attack surface expands. Stay updated on Nvidia driver releases and, if you're running multi-tenant GPU workloads, review your isolation model.