Researchers at the University of Toronto have published GPUBreach, a new attack that chains GDDR6 Rowhammer bit-flips with memory-safety bugs in the NVIDIA GPU driver to achieve a root shell on the host system — even with IOMMU enabled. Full details drop at IEEE Symposium on Security & Privacy on April 13 in Oakland, but the disclosure timeline and threat model are already public.

What Is GPUBreach?

GPUBreach extends the Rowhammer attack family to GPU memory. Rowhammer is a well-understood DRAM vulnerability: repeatedly reading rows of memory causes bit-flips in adjacent rows due to electrical interference. GPUBreach shows the same principle works against GDDR6, the memory standard used by consumer and workstation NVIDIA GPUs (RTX 20-series through RTX 50-series) and AMD RX 6000-series and newer.

The attack chain is three steps:

  1. GDDR6 bit-flip induction: An unprivileged CUDA kernel hammers GPU memory, inducing bit-flips in GDDR6 rows adjacent to the target. No root or special privileges are required to start — only GPU access.
  2. GPU page-table corruption: Bit-flips corrupt GPU page table entries (PTEs), granting the attacker arbitrary read/write access to all GPU memory from their unprivileged CUDA context.
  3. CPU privilege escalation via driver bugs: Rather than using DMA to attack host memory directly (the path that IOMMU blocks), GPUBreach exploits newly discovered memory-safety vulnerabilities in the NVIDIA GPU kernel driver. A GPU-side write that the driver trusts triggers kernel-level code execution on the CPU, resulting in a root shell on the host.

This third step is the key differentiator. Prior GPU Rowhammer work (GPUHammer, 2021) was stopped by IOMMU. GPUBreach routes the escalation through the NVIDIA driver instead, making IOMMU irrelevant.

Two concurrent research groups — GDDRHammer (UNC Chapel Hill / Georgia Tech / MBZUAI) and GeForge (Purdue / Rochester / UWA / Clemson / HydroX AI) — also demonstrate GDDR6 page-table corruption and will present at IEEE S&P 2026 alongside GPUBreach. Neither achieves full CPU privilege escalation with IOMMU enabled; GPUBreach is the first to do so.

Who Is Affected?

Directly vulnerable: Any system running an NVIDIA GPU with GDDR6 memory and a standard NVIDIA Linux or Windows driver, where an untrusted user can submit CUDA kernels. This covers:

  • NVIDIA RTX 20xx, 30xx, 40xx, and 50xx (GeForce, RTX Workstation series)
  • NVIDIA RTX A-series workstation GPUs (A4000, A5000, A6000 — the tested hardware was an RTX A6000)
  • AMD GPUs with GDDR6 are susceptible to the bit-flip phase but the exploit chain is NVIDIA driver-specific and was not demonstrated cross-vendor

Largely protected (GDDR6 not used; HBM with on-die ECC instead):

  • NVIDIA A100 (HBM2e), H100 (HBM3), H200 (HBM3e), B100/B200 — datacenter flagship GPUs used in AWS p4/p5 instances, Google Cloud A3, Azure ND series
  • These GPUs activate Rowhammer defenses automatically via SEC-DED ECC built into the HBM stack

High-risk scenarios for infrastructure engineers:

  • Multi-tenant GPU sharing: container workloads or Kubernetes GPU scheduling that places multiple jobs on the same physical GPU are directly in scope. One tenant can attack another tenant’s workloads, or escalate to the node.
  • CI/CD runners with GPU access: pipelines that execute user-supplied code (model fine-tuning, compilation, testing) on GPU hardware
  • AI inference endpoints where the model input can influence GPU kernel behavior (indirect triggering is theoretical but noted by researchers as a future research direction)
  • Edge and workstation deployments (RTX 3090/4090 in on-prem ML clusters) with no ECC support

CVE Status and Patch Availability

No CVE has been assigned. No driver patch is available as of publication. NVIDIA was notified on November 11, 2025 alongside Google, AWS, and Microsoft. Google acknowledged the report with a $600 bug bounty. NVIDIA has not published a security bulletin for the driver-level memory-safety vulnerabilities that GPUBreach exploits.

The researchers will release their paper and proof-of-concept code following the April 13 IEEE S&P presentation.

Mitigations

Short-term options are limited:

Enable ECC on supported hardware. Workstation-class NVIDIA GPUs (RTX A-series, RTX Pro series) support ECC mode. Enable it with:

1
2
3

sudo nvidia-smi -e 1
# requires reboot
sudo reboot

Verify ECC is active post-reboot:

1

nvidia-smi --query-gpu=ecc.mode.current --format=csv,noheader

ECC activates SECDED error correction on GDDR6 writes, which detects and corrects the single-bit flips GPUBreach relies on for PTE corruption. Consumer GeForce cards (RTX 3090, 4090, etc.) do not support ECC mode — there is no software mitigation for these GPUs.

Restrict GPU access in multi-tenant environments. If you’re running shared Kubernetes GPU clusters with untrusted workloads:

  • Audit GPU sharing policies (MIG partitioning on A100/H100 is immune; time-slicing on RTX hardware is not)
  • Consider restricting GPU access to vetted workloads only until a driver patch ships
  • Review your GPU operator configuration and ensure workloads in separate namespaces do not share physical GPU slices

Monitor for anomalous CUDA API usage. Rowhammer attacks involve high-frequency memory access patterns that can be detected via GPU performance counters. NVIDIA’s Nsight or DCGM can surface abnormal memory access rates.

Prefer HBM-based datacenter GPUs for sensitive multi-tenant compute. If your threat model includes untrusted CUDA workloads, H100/A100 with HBM provide hardware Rowhammer protection that consumer GDDR6 cards do not.

References