[{"content":" GPUThor Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs\nACM CCS 2026 The Hague · 15–19 November 2026 Chris S. Lin, Joyce Qu, Aditya Rajeev, and Gururaj Saileshwar University of Toronto 📄 Read the Paper 💻 Code \u0026amp; Artifact (public 15 Nov 2026) 🎓 Cite this work 🛡️ NVIDIA Security Notice GPUThor is the first Rowhammer attack on NVIDIA GPUs to break through error-correcting codes (ECC), NVIDIA's defense against this threat. Rowhammer is a DRAM flaw: repeatedly hammering a memory row flips bits in its neighboring rows, causing data corruptions. By reverse-engineering how GPUs merge repeated memory requests and when the memory's built-in defense kicks in, GPUThor hammers its target 6.6× harder than prior GPU attacks, producing 500×–23,500× more bit flips. This corrupts multiple bits at once and overwhelms the ECC, enabling the first GPU denial-of-service attacks and root-level privilege escalation on ECC-protected GPUs. 23,500× more bit flips than GPUHammer, the first GPU Rowhammer attack 377,000 bit flips per GB on an RTX A5000 — close to CPU attack rates First Rowhammer exploits on ECC-enabled GPUs 4 affected GPUs RTX A4000, A4500, A5000, A6000 Exploits Enabled by GPUThor:\nECC, NVIDIA\u0026rsquo;s recommended defense, no longer holds. GPUThor induces 387 double-bit errors that ECC detects but cannot correct, and 2 triple-bit errors that ECC silently \u0026ldquo;repairs\u0026rdquo; into the wrong value. Denial of service, and GPUs declare themselves defective. On an A6000 with ECC enabled, GPUThor forces one GPU reset every 2 hours, killing every job running on the card; within a day, the GPU flags itself as due for replacement (RMA-ready). Privilege escalation to root, with ECC enabled. By corrupting GPU page tables, an unprivileged GPU program escalates all the way to a root shell on the host CPU, the first such system takeover on an ECC-protected GPU. Background: Rowhammer on GPUs # DRAM stores each bit as charge in a cell, and cells are packed into rows that sit very close together. Rowhammer is a read-disturbance failure: repeatedly activating (\u0026ldquo;hammering\u0026rdquo;) one row leaks charge from the cells in adjacent rows and flips their bits. No permission to those neighboring rows is needed, which is what makes Rowhammer useful for data tampering, sandbox escapes, and privilege escalation. DRAM chips ship with an in-DRAM mitigation, Target Row Refresh (TRR): the chip samples frequently activated rows and issues a corrective refresh to their neighbors. Attacks evade TRR by mixing in decoy rows to overwhelm the sampler.\nOur previous work, GPUHammer (2025), first demonstrated Rowhammer bit flips in the GDDR6 memory of NVIDIA GPUs, and follow-up work, GPUBreach (2026) showed the privilege escalation all the way to root shell on the CPU. At that time, NVIDIA recommended enabling ECC as a mitigation (NVIDIA Security Notice, 2025). All prior GPU attacks are defeated once ECC is enabled since they yield only tens to hundreds of flips per GB that can be corrected by the ECC on the NVIDIA GPUs; these bit flip rates are orders of magnitude below CPU attacks such as Blacksmith (≈550,000 flips/GB on DDR4).\nWhat GPUThor does differently # Prior GPU attacks hammer uniformly: the aggressor row next to the victim is activated about as often as the decoys, so most of the effort lands on rows that do not matter. CPU attacks moved to non-uniform patterns years ago; no GPU attack had managed it. GPUThor enables non-uniform hammering on GPUs by overcoming two undocumented behaviors as follows.\n1 Defeat GPU memory request coalescing The GPU memory subsystem merges repeated accesses to the same address, so naively repeating an access collapses back into a single DRAM activation. GPUThor characterizes coalescing within a warp, across warps, and across cache lines, and finds that accesses issued from different warps to different cache lines of the same row survive as distinct activations. Its kernels distribute the repeated accesses accordingly. 2 Locate the TRR mitigation instances Prior GPU attacks assumed TRR acts once per refresh interval (tREFI, ≤1.9 µs in GDDR6). Using bit-flip reproducibility as a side channel, GPUThor finds that mitigation on Ampere GDDR6 is issued roughly once every 72 tREFIs. Patterns whose length divides 72 stay synchronized with that schedule and reliably reproduce flips. Together these yield the attack pattern below: a 6-tREFI pattern sustaining ≈110,000 aggressor activations per refresh window, 6.6× the intensity of prior uniform GPU attack patterns.\nAggressor row (adjacent to the victim) Decoy row (to evade TRR) One warp = 3 accesses Prior GPU attacks Uniform The aggressor is activated about once per tREFI — no more than any decoy — so its share of each TRR sampling window is small. W1W2W3⋯W8 tREFI 1⋯ tREFI 2⋯ tREFI 3⋯ tREFI 4⋯ tREFI 5⋯ tREFI 6⋯ ≈1 aggressor activation per tREFI GPUThor Non-uniform All 8 warps activate the aggressor for five tREFIs; the sixth is decoys only, which keeps the pattern hidden from the TRR sampler. W1W2W3⋯W8 tREFI 1⋯ tREFI 2⋯ tREFI 3⋯ tREFI 4⋯ tREFI 5⋯ tREFI 6⋯all decoys ≈6.6× aggressor activations per tREFI Each square is one memory access; a boxed group of three is one warp (a group of GPU threads), and ⋯ stands in for warps 4–7. GPUThor issues at most one aggressor activation per warp, to avoid coalescing. (Simplified schematic of Figure 8 in the paper.) Bit flips measured # Rowhammer bit flips per gigabyte of memory log scale GPUThor reaches 72,000–377,000 flips/GB across four GPUs, in the range of the strongest CPU attacks. Bars are on a logarithmic scale (axis spans 1 to 106); the bold multiplier on each bar is relative to GPUHammer. Measured over 24 hours per bank, four banks per GPU, with ECC disabled. GPUHammer 2025 · first GPU attack 1× 16 GDDRHammer prior best GPU attack 47× 758 GPUThor NVIDIA A6000 7,155× 114,488 GPUThor NVIDIA A5000 23,597× 377,552 Blacksmith comparable CPU attack (DDR4) ~550,000 Higher flip density also shortens the search for an exploitable flip. An end-to-end privilege-escalation exploit that takes 21.9 hours with GPUHammer patterns on an A6000 completes in 1.1 minutes with GPUThor.\nExploits # 🛡️GPUThor Defeats ECC on NVIDIA GPUs GPU ECC can repair one flipped bit and detect a second flip within 16 B of data. At such granularity, GPUThor induces 387 double-bit errors, which ECC detects but cannot correct, and 2 triple-bit errors, which it silently \"repairs\" into the wrong value. 💥Induces Denial of Service and Makes GPU RMA-ready An uncorrectable error kills the GPU and all running jobs. On an A6000 with ECC enabled, GPUThor triggers one GPU reset every 2 hours, inducing Denial-of-Service; in a day, the GPU declares itself defective and due for replacement, once it can no longer remap rows with uncorrectable errors. 🔓Privilege Escalation \u0026 System Takeover with ECC Enabled Flipping bits in GPU page tables (like GPUBreach) lets an unprivileged program read and write any memory and even open a root shell on the host. GPUThor enables a root-shell for the first time with ECC enabled on GPUs with both double and triple bit errors. Affected GPUs # We evaluated four Ampere-class NVIDIA workstation GPUs with GDDR6 memory — cards widely used in AI workstations and in the cloud. All four are vulnerable to bit flips with our attack and an unprivileged CUDA kernel can exploit these to mount the attacks above.\nGPU Memory Bit flips / GB (ECC disabled) vs. GPUHammer RTX A5000 24 GB GDDR6 377,000 23,597× RTX A6000 48 GB GDDR6 114,000 7,155× RTX A4500 20 GB GDDR6 75,000 4,689× RTX A4000 16 GB GDDR6 72,000 4,548× Responsible disclosure # We reported this to NVIDIA prior to public disclosure We disclosed GPUThor to NVIDIA on 29 April 2026, and also to the major cloud providers (Google, Microsoft, AWS). At NVIDIA's request, the work was held under embargo until 25 August 2026, when NVIDIA released a security notice with guidance. Frequently asked questions # I already enabled ECC on my GPU. Am I safe? No. This is the paper's main finding. The SECDED ECC on these GPUs corrects single-bit errors, which was enough to stop earlier GPU attacks. GPUThor's higher hammering intensity produces double- and triple-bit errors within a single ECC-protected chunk, which ECC cannot correct and, in the triple-bit case, cannot even detect. We used these to crash GPUs and to escalate privileges with ECC enabled. ECC still raises the bar and remains worth enabling, but it can no longer be treated as a sufficient defense. Which GPUs are affected? We confirmed bit flips on four different NVIDIA Ampere GPUs with GDDR6 memory: the RTX A4000, A4500, A5000, and A6000. These are common in workstations and cloud instances. The attack technique is general, so other GPUs using similar memory and defenses may also be at risk. What about server GPUs like the A100 and H100 or newer GPUs like the Blackwell RTX 5090 or RTX 6000? We focused on workstation and cloud cards with GDDR6 memory. On the other memory types we tested — including HBM, GDDR6X, and newer GDDR7 — GPUThor's current patterns did not produce flips, likely because those chips use different internal defenses. However, we cannot rule out that alternative patterns can induce bit flips on those products and follow-up work can investigate this; newer HBM3 and GDDR7 also add on-die ECC, which reduces error visibility rather than preventing flips. How does GPUThor compare to prior attacks GDDRHammer and GeForge? Both GDDRHammer and GeForge attempt to improve the attack compared to GPUHammer. While they show 1.1x and 47x the number of bit flips per GB compared to GPUHammer, GPUThor demonstrates 7,155x to 23,597x bit flips per GB, demonstrating orders of magnitude increase in the threat. Could someone read or change my data on a cloud GPU? That is the risk this work demonstrates. When a GPU is time-shared between users (common in cloud AI services), an attacker running on the same card can flip bits in a victim's data and crash the shared GPU. Even if the GPU is not time shared, any untrusted code that runs on the GPUs (e.g., ML models requiring packages downloaded from the internet that may have been compromised) can escalate to root-level privileges, and serve as an entry-point for malware into the system. What should I do right now? Cloud operators should avoid sharing a single physical GPU across untrusted tenants, and monitor NVIDIA's error-correction counters — a spike is a strong indicator of an attack in progress. All GPU users should exercise care while runnning untrusted code on their GPU. A complete fix requires stronger hardware-level defenses in future GPUs. Mitigations # Stronger error correction. Adopting stronger error correction codes that correct multi-bit errors (e.g., Chipkill-class ECC) can raise the bar for attacks, but add storage and bandwidth overheads on top of the 6.25% already spent on SECDED in GDDR6. Hardware defenses. Adopting more principled defenses in GPU memories, such as Refresh Management (RFM) and Per-Row Activation Counting (PRAC) proposed in DDR5, can address the root cause and make attacks like GPUThor substantially harder. Monitoring. Administrators can monitor corrected-error counts as the exploit may result in several single-bit errors that are corrected along the way. This is however an imperfect defense as triple-bit flips can induce silent data corruptions, leaving no observable traces. Paper \u0026amp; citation # GPUThor appears at the ACM SIGSAC Conference on Computer and Communications Security (CCS \u0026lsquo;26), 15–19 November 2026, in The Hague, The Netherlands.\n📄 Read the full paper (PDF) 💻 Code \u0026amp; Artifact\nOur code and artifacts will be released publicly at github.com/sith-lab/gputhor on 15 November 2026.\n@inproceedings{lin2026gputhor, author = {Chris S. Lin and Joyce Qu and Aditya Rajeev and Gururaj Saileshwar}, title = {{GPUThor}: Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit {ECC}-Protected {GPUs}}, booktitle = {Proceedings of the 2026 ACM SIGSAC Conference on Computer and Communications Security (CCS \u0026#39;26)}, year = {2026}, location = {The Hague, The Netherlands}, publisher = {ACM}, } Acknowledgements # This research was supported by the Natural Sciences and Engineering Research Council of Canada (NSERC) and an NSERC–CSE Research Communities Grant. Any opinions expressed are solely those of the authors and do not represent the official views of the funding agencies or the Government of Canada.\n","date":"19 August 2026","externalUrl":null,"permalink":"/","section":"","summary":"","title":"","type":"page"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]