↓Skip to main content

IEEE S&P 2026

GPUBreach: Privilege Escalation Attacks on GPUs using Rowhammer

Chris S. Lin, Yuqin Yan, Guozhen Ding, Joyce Qu, Joseph Zhu, David Lie, Gururaj Saileshwar

University of Toronto

To appear at the 47th IEEE Symposium on Security & Privacy (Oakland 2026).

Read Paper (PDF) Code & Artifact (links will be active on April 13)

TL;DR
#

GPUBreach shows that GPU Rowhammer attacks can move beyond data corruption to real privilege escalation. By corrupting GPU page tables, an unprivileged CUDA kernel can gain arbitrary GPU memory read/write, and then chain that capability into CPU-side escalation by exploiting newly discovered memory-safety bugs in the NVIDIA driver. The result is system-wide compromise up to a root shell, without disabling IOMMU, unlike contemporary works, making GPUBreach a more potent threat.

At a glance
  • Primitive: Rowhammer bit-flips in GDDR6 corrupt GPU page tables.
  • Impact: Arbitrary GPU memory read/write, cross-process attacks.
  • Escalation: GPU-to-CPU root shell via driver memory-safety vulnerabilities.
  • Key point: Works with IOMMU enabled (unlike concurrent works).
Demo video

If the embedded player does not load, watch it directly on Dropbox.

What problem does this address?
#

Prior CPU Rowhammer exploits have compromised page tables and achieved privilege esclation. Yet on GPUs, earlier Rowhammer work (GPUHammer) mostly showed limited, untargeted bit flip flips that primarily degrade ML accuracy by flipping weights in ML models. It was unclear whether GPU Rowhammer could reach privilege escalation comparable to CPUs.

In this work, we investigate how GPU page tables, that live entirely in GPU memory, can be corrupted with Rowhammer to achieve privilege escalation (root shell) and arbitrary CPU and GPU memory access. But three key obstacles stood in the way:

Challenge Idea
Where are GPU page tables allocated? Reverse engineer the driver (including open-source patches) to find that page tables sit in contiguous 2 MB page-table regions (PT regions); only after an initial region fills do new regions come from the same pool as user data, enabling the row-sandwich layout Rowhammer needs.
Fill GPU memory with PTEs efficiently GPUBreach introduces allocation primitives using Unified Virtual Memory (UVM) to obtain 64 KB and 4 KB frames so PT regions can be allocated and densified with minimal memory requirements.
Place PTEs at attacker-chosen locations A timing side channel on UVM allocations exposes evictions to CPU memory when the GPU is nearly full, revealing when a new PT region appears; freeing chosen regions steers where page tables land next to known bit-flip sites.

Together, these pieces let the attacker massage page tables next to flippable rows, flip a PTE so the corrupted page-frame number points at another page-table page, and thereby gain control of its own page tables and arbitrary GPU R/W.

What we demonstrate
#

Evaluations use an NVIDIA RTX A6000 with GDDR6 (same class of setting as prior GPU Rowhammer work on this platform).

  1. GPU-side privilege escalation — Arbitrary read/write on GPU memory after page-table tampering, including cross-process access in time-sliced sharing.
  2. Post-quantum crypto on GPU — Leakage of secret keys from NVIDIA cuPQC, a library used to accelerate post-quantum cryptography, when keys reside in GPU DRAM during operations such as key exchange.
  3. Stealthy ML impact — By tampering with one branch in cuBLAS SASS in GPU memory, we universally drive accuracy down (for example from 80% accuracy to 0%), more stealthily than prior weight tampering attacks; we also showcase leakage of sensitive LLM weights.
  4. CPU privilege escalation (even with IOMMU enabled) — The compromised GPU issues DMA (using the aperture bits in PTEs) into a region of CPU memory that the IOMMU permits (the GPU driver’s own buffers). By corrupting this trusted driver state, the attack triggers memory-safety bugs in the NVIDIA kernel driver and gains an arbitrary kernel write primitive, which is then used to spawn a root shell. Crucially, this works without disabling the IOMMU, which all major vendors recommend keeping enabled (NVIDIA, AMD).
Why this matters operationally: Most production systems keep IOMMU enabled as baseline hardening against DMA attacks. GPUBreach shows that this alone is not sufficient once a malicious GPU can corrupt trusted driver state.

How does GPUBreach compare to concurrent work?
#

Two concurrent works — GDDRHammer (UNC Chapel Hill / Georgia Tech / MBZUAI) and GeForge (Purdue / Rochester / UWA / Clemson / HydroX AI) — also demonstrate GPU page-table corruption via GDDR6 Rowhammer and will appear at IEEE S&P 2026 alongside GPUBreach. All three works independently show that GPU Rowhammer can go beyond data corruption to achieve GPU-side privilege escalation. GPUBreach was independently and concurrently developed.

The key differentiator is CPU-side privilege escalation with the IOMMU enabled:

GPUBreach GDDRHammer GeForge
GPU page-table tampering via Rowhammer Yes Yes Yes
Arbitrary GPU memory R/W Yes Yes Yes
CPU memory access Yes Yes Yes
CPU privilege escalation (root shell) Yes No Yes
Works with IOMMU enabled Yes N/A No (requires IOMMU disabled)

Why does IOMMU matter? The IOMMU restricts which CPU physical addresses a GPU (or any PCIe device) can DMA into, and is the standard defense against DMA-based attacks. It is recommended to be enabled by NVIDIA, AMD, and Microsoft, and has been deployed on commodity hardware for over a decade. GeForge’s CPU exploit requires disabling the IOMMU, which removes this critical protection. GDDRHammer can read/write CPU memory through PTE aperture bits but does not achieve CPU privilege escalation (root shell).

GPUBreach instead targets memory-safety bugs in the GPU driver itself: even though the IOMMU correctly confines the GPU’s DMA to driver-owned buffers, our exploit corrupts metadata within those permitted buffers, causing the driver (running at kernel privilege on the CPU) to perform out-of-bounds writes that the attacker controls — bypassing IOMMU protection without needing it disabled.

Takeaway: IOMMU remains recommended; GPUBreach demonstrates a unique attack path that abuses trusted-driver logic that surpasses even IOMMU protections to achieve root shell.

Responsible disclosure
#

We disclosed this work to NVIDIA on 11 November 2025 and subsequently to Google, AWS, and Microsoft. Google awarded our disclosure a bug bounty award of USD 600. NVIDIA shared that they may update their existing security notice, Rowhammer July 2025, to include these impacts.

FAQs
#

How does this relate to GPUHammer?
#

GPUHammer showed that Rowhammer bit-flips are practical on GDDR6 on an A6000 and demonstrated untargeted attacks that degrade application outputs (e.g., ML model weight tampering). GPUBreach uses Rowhammer for targeted corruption of PTEs to obtain arbitrary GPU memory access and privilege escalation.

How does this relate to GDDRHammer and GeForge?
#

GDDRHammer and GeForge are concurrent works that will also appear at IEEE S&P 2026. All three share the GPU page-table Rowhammer approach on the GPU side. The critical distinction is in the CPU exploit: GeForge requires IOMMU to be disabled to access arbitrary CPU memory, while GDDRHammer accesses limited CPU memory via aperture bits without achieving privilege escalation. GPUBreach achieves full CPU privilege escalation (root shell) even with the IOMMU enabled, by exploiting memory-safety vulnerabilities in the GPU driver rather than bypassing the IOMMU.

Does ECC stop this?
#

As with other Rowhammer attacks, ECC can be helpful as a mitigation, since it can correct single-bit flips and detect double-bit flips. On server and workstation GPUs (e.g., RTX A6000), we advise enabling ECC as per the NVIDIA security notice. However, if attack patterns induce more than two bit flips (shown feasible on DDR4 and DDR5 systems), existing ECC cannot correct these and may even cause silent data corruption; so ECC is not a foolproof mitigation against GPUBreach. On desktop or laptop GPUs, where ECC is currently unavailable, there are no known mitigations to our knowledge.

Where is the artifact?
#

The reproduction package and scripts will be available soon on GitHub: sith-lab/gpubreach, after April 13.

Further information
#

Please see the paper PDF and the GitHub artifact, which will be active soon, after artifact evaluation finishes on April 13.

To cite this paper:

@inproceedings{lin2026gpubreach,
  author    = {Chris S. Lin and Yuqin Yan and Guozhen Ding and Joyce Qu and Joseph Zhu and David Lie and Gururaj Saileshwar},
  title     = {{GPUBreach}: Privilege Escalation Attacks on {GPU}s using Rowhammer},
  booktitle = {Proceedings of the 47th {IEEE} Symposium on Security and Privacy},
  year      = {2026},
  series    = {SP '26},
}

Acknowledgements
#

This research was supported by Natural Sciences and Engineering Research Council of Canada (NSERC) Discovery Grants under funding reference number RGPIN-2023-04796 and RGPIN-2018-05931, and an NSERC-CSE Research Communities Grant under funding reference number ALLRP-588144-23. David Lie is also supported by Tier 1 Canada Research Chair CRC-2019-00242. Any research, opinions, or positions expressed in this work are solely those of the authors and do not represent the official views of NSERC, the Communications Security Establishment Canada, or the Government of Canada.

CSE logo
NSERC logo