News

GDDRHammer, GeForge, GPUBreach: NVIDIA GDDR6 Rowhammer Attacks Enable Full System Takeover

GDDRHammer, GeForge, GPUBreach: NVIDIA GDDR6 Rowhammer Attacks Enable Full System Takeover

Three independent research attacks — GDDRHammer, GeForge, and GPUBreach — have demonstrated practical Rowhammer exploitation of NVIDIA Ampere-generation GPUs equipped with GDDR6 memory, with two of the attacks achieving full root-level compromise of the host CPU from GPU memory manipulation. GDDRHammer and GeForge require IOMMU to be disabled, which is the default BIOS configuration on most consumer and enterprise hardware. GPUBreach bypasses IOMMU entirely via driver-level bugs, achieving privilege escalation even when the protection is active.

Technical Details: Three Attacks, One Threat Class

Rowhammer (also written "Row Hammer") is a class of hardware vulnerability in DRAM (Dynamic Random-Access Memory) chips. DRAM stores data in arrays of memory cells organized in rows. When a single memory row is accessed — "hammered" — thousands of times per second, the resulting electrical interference can flip bits in physically adjacent rows, corrupting data that was never directly accessed. This is not a software bug that can be patched in the traditional sense; it is a consequence of the physical proximity of memory cells as DRAM density has increased.

Prior Rowhammer research has demonstrated the attack extensively against LPDDR4 and DDR4 memory in CPUs. The 2026 research extends the attack to GDDR6 (Graphics Double Data Rate 6), the high-bandwidth memory type used in NVIDIA's Ampere-generation GPUs including the RTX 3060 and RTX A6000.

GDDRHammer and GeForge were developed by two separate university research teams who arrived at nearly identical results independently. After discovering this, they coordinated publication. Both attacks work by:

  • Reverse-engineering the proprietary row-mapping of GDDR6 DRAM chips (the mapping is not publicly documented by NVIDIA or memory manufacturers), using timing side-channels to infer the physical layout
  • Identifying access patterns that bypass Target Row Refresh (TRR), the primary industry defense against Rowhammer in modern DRAM
  • Triggering bit-flips in VRAM (the GPU's video memory) to manipulate GPU page tables — the internal data structures that track which VRAM addresses correspond to which physical memory locations
  • Using the corrupted GPU page tables to gain arbitrary read/write access over host CPU RAM, escalating from GPU VRAM corruption to full system compromise

GDDRHammer induced up to 1,171 bit-flips on an NVIDIA RTX 3060 and 202 on an RTX A6000 during testing — approximately 64 times more efficient than prior GPU Rowhammer work. These attacks require IOMMU to be disabled, which is the default in BIOS/UEFI settings on most systems. IOMMU (Input-Output Memory Management Unit — a hardware component that controls which memory regions a peripheral like a GPU can access) prevents the GPU from directly accessing CPU RAM under normal circumstances.

GPUBreach is a third independent attack that takes a different approach: rather than relying on hardware bit-flips, it exploits conventional memory safety bugs in NVIDIA's GPU drivers. The driver-level vulnerability allows privilege escalation to root from within a GPU workload, achieving full system compromise even when IOMMU is enabled. GPUBreach's driver component is potentially patchable via software updates, unlike the hardware-level Rowhammer vulnerability itself.

Affected Hardware and Scope

Confirmed vulnerable to GDDRHammer/GeForge:

  • NVIDIA GeForce RTX 3060 (Ampere architecture, GDDR6)
  • NVIDIA RTX A6000 (Ampere architecture, GDDR6)
  • All NVIDIA Ampere-generation GPUs using GDDR6 memory are assessed as affected

Not vulnerable to GDDRHammer/GeForge:

  • GPUs using GDDR6X, GDDR7, or HBM (High Bandwidth Memory) are not affected by these specific attacks

GPUBreach affects systems running vulnerable NVIDIA drivers regardless of GPU memory type.

The practical risk is highest in environments where multiple users share GPU resources — AI/ML training clusters, GPU-as-a-service cloud offerings, research computing clusters, and virtual desktop infrastructure (VDI) running GPU workloads. In these environments, an attacker with access to a GPU workload (e.g., a malicious or compromised machine learning job) could escalate to compromise the host system and any co-resident tenants.

NVIDIA issued a Security Notice on Rowhammer in July 2025 acknowledging the industry-wide DRAM issue. No CVE (Common Vulnerabilities and Exposures — a standardized identifier for publicly disclosed security flaws) was assigned for the hardware-level Rowhammer issue itself, since it reflects a physical DRAM design characteristic rather than a specific software flaw eligible for traditional vulnerability tracking.

Exploitation Status and Threat Landscape

These attacks are currently academic research demonstrations. GDDRHammer, GeForge, and GPUBreach were disclosed by university research teams with responsible disclosure timelines, and no public exploitation tool has been released. However, the techniques are now documented in detail, and the conditions required for exploitation are present on the majority of affected systems (IOMMU disabled by default).

Tom's Hardware and Kaspersky have assessed the practical exploitation risk as highest in multi-tenant GPU cloud environments, where:

  • Multiple customers share physical GPU hardware
  • Attackers can submit jobs to shared computing queues (e.g., SLURM, Kubernetes GPU pods)
  • A malicious ML job could escalate to host-level access and pivot to other tenants

This threat model is directly relevant to every major cloud provider offering GPU instances (AWS EC2 P-series, Google Cloud A-series, Azure ND-series) and specialized AI compute providers. The predecessor attack GPUHammer, demonstrated at USENIX Security 2025, established that GPU Rowhammer was feasible; the 2026 research demonstrates that it scales to full system compromise.

CISA and NVIDIA have not added the hardware-level Rowhammer issue to the Known Exploited Vulnerabilities (KEV) catalog, as no active exploitation in the wild has been confirmed. The GPUBreach driver component may receive formal CVEs in future NVIDIA security bulletins.

What You Should Do Right Now

  • Enable IOMMU in BIOS/UEFI settings — This is the single highest-impact mitigation. IOMMU restricts GPU access to designated memory regions, blocking the primary path used by GDDRHammer and GeForge to escalate from VRAM to host CPU RAM. On Intel systems, look for "VT-d" (Virtualization Technology for Directed I/O); on AMD systems, look for "AMD-Vi" or "IOMMU." Enable it in BIOS and verify via the OS (dmesg | grep -e DMAR -e IOMMU on Linux). Note that enabling IOMMU may impose 5–10% performance overhead on GPU workloads.
  • Enable ECC memory on compatible cards — ECC (Error Correction Code — memory that automatically detects and corrects single-bit errors) can mitigate Rowhammer exploitation by catching and correcting the bit-flips the attack relies on. The RTX A6000 and other workstation/server-class NVIDIA GPUs support ECC; consumer GeForce cards do not. Enable ECC via nvidia-smi --ecc-config=1 (requires reboot).
  • Apply all NVIDIA driver updates — GPUBreach exploits driver-level bugs that may be addressed in forthcoming NVIDIA driver security updates. Run nvidia-smi to check driver version and compare against NVIDIA's security update page.
  • Audit multi-tenant GPU environments — Cloud providers and on-premises HPC operators running shared GPU workloads should verify IOMMU is enforced between tenants as a baseline isolation control.
  • Prefer GDDR7 or HBM for new hardware procurement — When purchasing new GPU infrastructure, select hardware with GDDR7 or HBM memory, which is not vulnerable to current GDDRHammer/GeForge attack variants.
  • Monitor for anomalous VRAM access patterns — Security tools that monitor GPU memory access patterns for anomalous behavior can provide early warning, though no commercial tool currently provides this capability out of the box.

Background: Understanding the Rowhammer Risk

Rowhammer attacks against CPUs have been studied since 2014, when Google Project Zero demonstrated that exploiting DRAM bit-flips could escalate Linux kernel privileges. Since then, DRAM manufacturers introduced Target Row Refresh (TRR) as a hardware-level defense, and the industry largely considered the threat mitigated for newer memory types. The GDDRHammer and GeForge research proves that TRR bypass remains achievable with sufficient reverse engineering of proprietary DRAM geometry.

The extension to GPUs adds a new dimension: GPU memory operates at substantially higher bandwidth than system DRAM, the row mapping is proprietary and harder to defend, and GPU workloads are increasingly running in multi-tenant shared environments where adversarial co-tenancy is a realistic threat model. A research institution running public GPU compute jobs, a cloud provider renting GPU time for AI inference, or a university cluster accessible to external researchers all face elevated risk under this threat model.

Aviatrix's threat research on GPUBreach notes that the most concerning vector is not individual workstations but rather AI training infrastructure: large-scale GPU clusters running diverse, partially-untrusted workloads from multiple sources (contractors, research partners, automated pipelines) where IOMMU may have been disabled for performance reasons or simply never checked.

Conclusion

GDDRHammer, GeForge, and GPUBreach collectively demonstrate that NVIDIA Ampere GDDR6 GPUs — the backbone of most AI/ML infrastructure deployed in 2021–2024 — can be exploited to achieve full host system compromise. The immediate mitigation is straightforward: enable IOMMU in BIOS settings. The majority of systems running affected hardware have this protection disabled by default. For organizations running shared GPU compute environments, this should be treated as a critical configuration remediation item, not a deferred maintenance task.

For any query contact us at contact@cipherssecurity.com

Leave a Reply

Your email address will not be published. Required fields are marked *