GPUBreach: Rowhammer's GDDR6 attack that could turn the GPU into a system access door

A new vector of attack that researchers at the University of Toronto have baptized as GPUBreach shows that Rowhammer-type vulnerabilities, traditionally associated with CPU DRAM memories, can also be exploited with GDDR6 on graphic cards to achieve privilege escalation and, ultimately, a complete system take.

The technical key to GPUBreach is to induce bit volts (bit-flips) in GDDR6 memory of the GPU in a controlled way. These errors not only corrupt data blocks: the researchers managed to affect the memory management structures of the GPU itself, in particular the entries of the page tables (PTEs). By damaging PTEs, a CUDA kernel without privileges is made to obtain arbitrary reading and writing about the memory of the GPU, a capacity that can be chained with system controller failures to take the exploitation of the GPU side to the CPU space and obtain root privileges.

To understand gravity it is necessary to remember what Rowhammer is: it is a physical effect on DRAM memories that allows, through repeated and carefully targeted accesses to adjacent rows, to force bits to be invested in neighbouring cells. GPUBreach applies this principle to GDDR6 chips used by many modern GPU and shows that the result can escape from the scope of mere data corruption and become a way of climbing privileges.

That the explosion will corrupt the GPU's page tables is what makes the jump especially dangerous: The PTEs define which memory pages exist and with which permissions; if a malicious process rewrites those entries it can redirect access, map foreign regions or mutate protections, and thus read and modify memory both from the GPU and potentially force conditions usable by the system controller.

The University of Toronto team presented its work on the project's website GPUBreach and will publish the full technical article on 13 April at the IEEE Symposium on Security & Privacy; the preliminary technical version is already available at document and the playcode was deposited in GitHub in sith-lab / gpubreach.

In their experiments, researchers used a RTX A6000 NVIDIA with GDDR6, a GPU frequent in the development and training environments of IA models. This puts the problem in a critical place: infrastructures and workstations that run automatic learning loads usually expose APIs and environments where they can load kernel and tasks by users that are not always completely isolated.

An obvious defense against bit flips are ECC memories: they correct a bit's errors and detect many double flips. But The ECC protection is not infallible against multiple errors and is not standard in consumption GPUs. The authors also point out that the use of IOMMU protection - the hardware that manages and restricts direct device memory access (DMA), designed to prevent a device from freely accessing arbitrary RAM regions - does not prevent GPUBreach when the GPU is able to corrupt the status of the trusted controller. For an introduction to the IOMMU concept, see Intel's documentation on VT-d: What VT-d is.

The authors reported their findings to the affected suppliers (NVIDIA, Google, AWS and Microsoft) and some of these companies have already responded. Google recognized the report and awarded a reward; NVIDIA indicated that it can extend its July 2025 security notice to reflect new GDDR6-related attack routes. The notice of NVIDIA is available at your support page. It is important to monitor the official warnings of manufacturers to apply patches and mitigation as soon as they are available.

From the practical point of view, GPUBreach transcends the mere theoretical demonstration: it not only shows that bit- flips can be induced in GDDR6 in a reproducible way, but that these corruptions can be used to alter critical structures and raise privileges without the need to deactivate protections such as the IOMMU, something that made the difference against previous work on Rowhammer in GPUs. A previous investigation of the same group, known as GPUHammer, had already demonstrated the viability of Rowhammer in GPU memoirs; GPUBreach takes the post further, towards complete system-level escalation.

What can users and administrators do right now? First, minimize risk by avoiding running unverified GPUs code that handle sensitive data or belong to shared environments. Second, where possible, choose ECC-supported hardware and activate the mitigation recommended by the manufacturer. Third, keep up-to-date controllers and firmwares and apply supplier security settings to restrict who can load kernel on GPU devices. Finally, in cloud environments, review the GPU isolation policies offered by the supplier and demand guarantees on hardware / firmware mitigation.

GPUBreach is a powerful reminder that the attack surface of the GPU is no longer peripheral: GPUs are now critical and complex components that manage memory, make virtualization and expose interfaces that, poorly protected, offer roads to large-scale commitments. The complete research will be available in the technical publication and repository listed above, and its presentation in the IEEE S & P will allow the community to review it in detail and work on countermeasures.

For those who want to deepen, in addition to the project page and the paper, it is appropriate to follow the specialized technical coverage and safety notes of the manufacturers. Keep informed and implement a policy of minor privileges and isolation in environments using GPU will mitigate the risk until there are patches and hardware-level design measures that resolve these new categories of attacks.