Rowhammer Attacks Against NVIDIA GPUs Can Lead to Full Host ...

[carlospolop]

🤖 Automated Content Update

This PR was automatically generated by the HackTricks News Bot based on a technical blog post.

📝 Source Information

• Blog URL: https://www.schneier.com/blog/archives/2026/05/rowhammer-attack-against-nvidia-chips.html
• Blog Title: Rowhammer Attacks Against NVIDIA GPUs Can Lead to Full Host Compromise
• Suggested Section: Hardware/Physical Access -> Physical Attacks (or a new Rowhammer / GPU Rowhammer subsection)

🎯 Content Summary

This post summarizes three recent Rowhammer-style attacks against NVIDIA Ampere-generation GPUs that move GPU fault injection from “just memory corruption” to full host compromise. The core idea is that induced bit flips in GDDR6 do not merely corrupt application data: they can corrupt GPU virtual-memory metadata itself. Once page-translation structures are altered, the attacker can forge mappings, obtain arbitrary GPU memory read/write, and then pivot into host CPU memory access for complete sy...

🔧 Technical Details

A powerful GPU Rowhammer exploitation pattern is to target GPU virtual-memory metadata instead of ordinary data buffers. By repeatedly hammering selected GDDR rows and using memory massaging to place page-translation structures in vulnerable physical locations, an attacker can induce bit flips in objects such as the last-level page table or last-level page directory. Those flips can then be converted into forged page mappings, which upgrades a hardware disturbance bug into arbitrary GPU memory read/write.

If the GPU memory-management path can reach host memory, the forged GPU mappings can be used as a pivot from GPU memory control into arbitrary host CPU memory access. In systems where IOMMU is disabled, corrupting GPU paging metadata may let the attacker read or write host memory broadly enough to fully compromise the machine. The general lesson is that Rowhammer becomes much more dangerous when the corrupted target is n...

🤖 Agent Actions

I’m mapping the repository first and then I’ll read the nearest hardware/physical attack pages plus any existing Rowhammer coverage before deciding whether this belongs in an existing file or needs a new page.
I found only one live hardware attack page in the published tree plus a todo fault-injection draft. I’m reading both the published hardware pages and a few neighboring methodology pages now to see whether Rowhammer already fits cleanly into physical-attacks.md or whether there is an existing lower-level hardware page I should reuse.
I’ve confirmed there’s no existing published Rowhammer page in the tree. The live documentation path that fits best is src/hardware-physical-access/physical-attacks.md; the only other relevant hardware writeups are still under src/todo/, so I’m validating the paper details now before drafting a compact GPU Rowhammer subsection.
The technical picture is clearer now: the reusable technique is not “GPU Rowhammer” in the abstract, but “Rowhammering GPU page-translation metadata, then turning one corrupted mapping into arbitrary GPU memory access and finally a host pivot.” I’m checking the exact mitigation and scope wording once more so the new section stays accurate and does not over-claim beyond the papers.
I’ve finished the placement decision. The edit is going into physical-attacks.md right after the RAM section, and I’m keeping it scoped to one concise section plus reference updates so it stays aligned with the rest of the page instead of turning into a standalone paper summary.
I’m applying the edit now. The patch adds one new section and only extends the existing reference list; no new files or summary links are needed because this already fits the published physical-attacks page cleanly.
The content is in place. I’m doing one last sanity pass with git diff --check and a focused reread so I don’t leave behind markdown breakage or wording that overstates what the papers actually demonstrated.
Updated physical-attacks.md with a new GPU Rowhammer Against Page Tables section. It captures the reusable technique rather than the specific news item: hammering GDDR6 to corrupt GPU page-table/page-directory metadata, using memory massaging to place those structures in vulnerable rows, pivoting from forged GPU mappings to arbitrary GPU memory access, and then to host compromise with the correct IOMMU/ECC caveats from GDDRHammer, GeForge, GPUBreach, and NVIDIA’s guidance.

I also extended the file’s references section with the Schneier post, the primary papers, and NVIDIA’s notice. No new file was created, and git diff --check is clean.

---

This PR was automatically created by the HackTricks Feed Bot. Please review the changes carefully before merging.

[carlospolop]

🔗 Additional Context

Original Blog Post: https://www.schneier.com/blog/archives/2026/05/rowhammer-attack-against-nvidia-chips.html

Content Categories: Based on the analysis, this content was categorized under "Hardware/Physical Access -> Physical Attacks (or a new Rowhammer / GPU Rowhammer subsection)".

Repository Maintenance:

• MD Files Formatting: 973 files processed

Review Notes:

• This content was automatically processed and may require human review for accuracy
• Check that the placement within the repository structure is appropriate
• Verify that all technical details are correct and up-to-date
• All .md files have been checked for proper formatting (headers, includes, etc.)

Bot Version: HackTricks News Bot v1.0