GPUBreach: Rowhammer Attacks Cross the GPU-CPU Boundary
🇩🇪 Auf Deutsch lesen~4 min read
SecurityHardwarerowhammergpunvidiaprivilege-escalationgpubreachhardware-securityiommu
Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowSave products you love by clicking the heart icon.
Benchmark: Qwen3.8-27B with hybrid attention/SSM architecture on RTX 4080 Laptop. 19% prefill degradation over 64x input, constant 2.76 tok/s generation, and 128k context in 8.8 GB VRAM.
Rowhammer has been a known class of DRAM attacks for over a decade. The mechanism is straightforward: repeatedly accessing a row of memory cells causes electrical charge to leak into adjacent rows, flipping bits from 0 to 1 or vice versa. What changes with GPUBreach, presented at IEEE S&P 2026 in Oakland, is the attack surface. For the first time, Rowhammer has been used to achieve full privilege escalation from a GPU across the PCIe bus into CPU memory, bypassing the IOMMU protections that were designed to prevent exactly this.
The attack chain exploits the convergence of three capabilities that modern GPUs provide: large GDDR6 memory arrays (which use the same DRAM technology as system RAM), direct memory access (DMA) over PCIe, and programmable page tables that map GPU virtual addresses to physical memory.
The attacker runs a standard Rowhammer pattern on GDDR6 memory from within a CUDA application. The target is not user data but the GPU's own page table entries. When a page table entry is flipped, the GPU's virtual address now maps to a different physical address than intended.
The Input-Output Memory Management Unit (IOMMU) is supposed to prevent a device from accessing memory outside its assigned regions. GPUBreach circumvents this because the Rowhammer-induced corruption occurs within memory regions the IOMMU has already authorised for the GPU. The corrupted page table entries point to physical addresses that are technically within the GPU's DMA window, but they map to CPU page table entries rather than GPU data buffers.
With the corrupted page table in place, the GPU's DMA engine writes to CPU physical memory. The attacker controls what data is written and where. The target is the CPU's page table entries for the current process.
By overwriting CPU page table entries, the attacker maps their process's memory pages with kernel-level permissions. The result is full root access on the CPU, achieved entirely from the GPU side of the PCIe bus.
Rowhammer on system RAM is well-understood, and mitigations exist: ECC memory can detect and correct single-bit flips, and memory controllers can implement targeted row refresh. GPUs introduce a new dimension because GDDR6 uses the same underlying DRAM technology but operates behind a DMA engine that the CPU memory controller cannot refresh.
NVIDIA's RTX A6000 workstation GPU was confirmed vulnerable in the paper. Consumer Ampere-series GPUs (RTX 3090, 3080, and similar) use the same GDDR6 memory and are likely affected, though the researchers did not explicitly test consumer cards. The critical gap: consumer GPUs do not support ECC. Enterprise data centre GPUs (A100, H100) include ECC and are partially mitigated, but the attack may still be feasible through multi-bit flips that overwhelm single-error correction.
The most severe implications are for multi-tenant GPU cloud environments. AWS, Google Cloud, and Azure all offer GPU instances where multiple virtual machines share physical GPU hardware. If a tenant can execute arbitrary CUDA code on a shared GPU, the GPUBreach attack chain allows them to escape the GPU boundary and gain root access on the host system, potentially compromising every tenant on that host.
Google awarded a $600 bug bounty for the disclosure. No CVE has been assigned for consumer GPUs, and no software mitigation exists for hardware that lacks ECC.
GPUBreach is not an isolated finding. It sits within a growing body of research that treats hardware accelerators as attack surfaces rather than trusted peripherals. As GPUs, TPUs, and other accelerators gain more direct memory access and more programmable memory controllers, the attack surface will only expand. The fix ultimately lies in hardware: memory controllers that can detect and refresh Rowhammered regions in GDDR, and IOMMU implementations that validate not just the DMA window but the semantic correctness of page table entries.
For now, organisations running untrusted CUDA workloads on shared GPU infrastructure should treat this as an unpatched privilege escalation vulnerability. The research paper and technical details are available at gpubreach.ca.