arXiv:2609.16546v1 [cs.CR] 15 Sep 2026
GPUThor: Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs Chris S. Lin
Joyce Qu
Aditya Rajeev
Gururaj Saileshwar
University of Toronto Toronto, Canada [email protected]
University of Toronto Toronto, Canada [email protected]
University of Toronto Toronto, Canada [email protected]
University of Toronto Toronto, Canada [email protected]
Abstract
1
GDDR memory in GPUs is vulnerable to Rowhammer attacks, where rapid memory accesses induce bit flips in adjacent cells, enabling data tampering and privilege escalation. However, prior GPU Rowhammer attacks trigger only tens to hundreds of bit flips, orders of magnitude fewer than CPU attacks, severely limiting their practical impact. This gap stems from the reliance of existing GPU Rowhammer attacks on uniform hammering patterns that activate aggressor and decoy rows equally, which results in low hammering intensity for aggressor rows. We present GPUThor, a high-intensity Rowhammer attack on NVIDIA GPUs leveraging non-uniform hammering. GPUThor reverse engineers GPU memory-access coalescing behavior to enable non-uniform hammering patterns on GPUs, that activate aggressor rows more intensely than decoy rows. Additionally, by identifying refresh instances when in-DRAM mitigations are applied, it constructs longer attack patterns that escape mitigation across refresh intervals, further increasing hammering intensity. Together, these techniques yield 500× to 23,500× more bit flips than prior GPU Rowhammer attacks, across several NVIDIA GPUs (A4000, A4500, A5000, A6000), reaching bit flip rates close to state-of-the-art CPU Rowhammer attacks. GPUThor also enables the first Rowhammer exploits on ECC-protected GPUs, inducing uncorrectable double and triple bit flips, making denial-of-service and privilege-escalation attacks practical even on GPUs with ECC enabled.
Rowhammer is a read-disturbance vulnerability in DRAM that enables attackers to induce bit flips in memory cells by rapidly activating neighboring rows [43]. Such attacks have been shown to enable data tampering, sandbox escapes, and privilege escalation exploits [8, 11, 21, 33, 34, 80]. While these were first discovered over a decade ago in CPU-based DDR memories, in the past year, several new Rowhammer attacks have been demonstrated on GPU-based GDDR memories [30, 48, 50, 90]. GPUHammer [48] first discovered Rowhammer bit flips on NVIDIA A6000 GPUs with GDDR6 memory, and used them to degrade ML model accuracy. Subsequent works [30, 50, 90] further showed that Rowhammer on GPUs can even lead to system-wide privilege escalation, establishing GPU Rowhammer attacks as a potent threat to system security. Despite these recent advances, the number of bit flips observed by recent GPU Rowhammer attacks remains orders of magnitude lower than what CPU-based attacks routinely achieve [28, 33], limiting their practicality. As shown in Table 1, GPUHammer [48] reported just 2 bit flips per DRAM bank on an A6000 GPU (16 flips per GB), while GeForge [90] and GPUBreach [50] reported 2.2 and 5.6 bit flips per bank (18 and 45 flips per GB) respectively on the same GPU. GDDRHammer [30] improved this to 94.8 bit flips per bank (758 flips per GB) using double-sided hammering patterns. In contrast, CPU-based Rowhammer attacks like Blacksmith [33] have demonstrated up to 550,000 flips per GB on DDR4 memories, orders of magnitude higher than the best GPU Rowhammer attacks. Due to the low bit flip rates on GPUs, enabling ECC on GDDR-based GPUs, which provides SECDED-level protections and corrects single-bit errors, effectively mitigates prior Rowhammer attacks. Accordingly, NVIDIA recommends enabling ECC as the primary defense against GPU Rowhammer attacks [61]. In this paper, we bridge the gap between GPU and CPU attacks, and demonstrate GPU Rowhammer attacks triggering up to 23,500× more bit flips than prior attacks, and show that ECC is an insecure mitigation for GPUs.
CCS Concepts • Security and privacy → Hardware attacks and countermeasures.
Keywords DRAM Rowhammer Attacks, GPU Security, GDDR DRAM ACM Reference Format: Chris S. Lin, Joyce Qu, Aditya Rajeev, and Gururaj Saileshwar. 2026. GPUThor: Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs. In Proceedings of the 2026 ACM SIGSAC Conference on Computer and Communications Security (CCS ’26), November 15–19, 2026, The Hague, Netherlands. ACM, New York, NY, USA, 17 pages. https: //doi.org/10.1145/3830454.3846620
This work is licensed under a Creative Commons Attribution 4.0 International License. CCS ’26, The Hague, Netherlands © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2871-6/2026/11 https://doi.org/10.1145/3830454.3846620
Introduction
Limitations of Prior Work. The fundamental limitation of prior GPU Rowhammer attacks is that they perform uniform hammering: all rows in the attack pattern, both aggressor rows (adjacent to the target victim) and decoy rows (used to evade in-DRAM mitigations), are activated at equal rates. Thus, a significant fraction of each refresh interval is spent hammering decoy rows rather than aggressors. In contrast, CPU Rowhammer attacks like Blacksmith [33] employ non-uniform hammering, activating aggressors at much higher intensity relative to decoys while still evading mitigations, dramatically increasing bit flips. No prior GPU Rowhammer attack has successfully utilized non-uniform hammering, leaving
CCS ’26, November 15–19, 2026, The Hague, Netherlands
the threat of Rowhammer on GPUs severely underestimated.1 However, adapting non-uniform hammering to GPUs is non-trivial and requires addressing a few key challenges (C1-C3). C1. Memory Access Coalescing. Unlike CPUs, we discover that GPUs have optimizations that aggressively coalesce memory accesses at multiple levels within warps and at the memory controller to amortize memory bandwidth. This coalescing prevents the finegrained control over activations that non-uniform hammering requires: repeated accesses intended to hammer aggressors at higher intensity may be merged into a single DRAM activation, collapsing a naive non-uniform pattern back to a uniform one. C2. Unknown Mitigation Instances. Non-uniform hammering can be more effective with the knowledge of when in-DRAM mitigations sample aggressors and issue mitigative refreshes, so that true aggressors can be hammered intensely outside the sampling window. In CPU DRAMs, these intervals are known to be aligned to multiples of tREFI [11, 33]. However, the sampling and mitigation instances in GDDR6 memories have not been characterized, leaving attackers unable to design effective non-uniform patterns. C3. Defeating ECC. Even if hammering intensity is amplified, workstation-class GPUs (e.g., A6000) support SECDED ECC that can correct single-bit errors and detect double-bit errors in GDDR6 memory. This makes it difficult for Rowhammer attacks to be successful in the presence of ECC. Our Approach. We introduce GPUThor, the first high-intensity, non-uniform Rowhammer attack on NVIDIA GPUs. Our approach is enabled by reverse-engineering the micro-architectural behavior of GPU memory accesses and GDDR6 in-DRAM mitigations. First, to address memory request coalescing (C1), we systematically characterize the behavior of repeated memory requests on GPUs, within and across warps. We find that while repeated requests within a single warp are aggressively coalesced at the memory controller, requests across warps are typically not coalesced. Moreover, when targeting different cachelines from across warps, requests further have minimal interference at the cache level. Leveraging this, we design hammering kernels that distribute repeated accesses to a row across warps on independent cachelines within a row, ensuring distinct repeated activations. This yields a 2–3× increase in hammering intensity over prior works [30, 48, 50, 90]. Second, to overcome the unknown mitigation instances (C2), we reverse-engineer the Target Row Refresh (TRR) behavior on Ampere GPUs with GDDR6 memories. We discover that mitigations are issued approximately once every 72 tREFIs, rather than once per tREFI as assumed by prior works [48, 50]. Leveraging this, we develop non-uniform attack patterns spanning up to 6 tREFIs, with the first five tREFIs interleaving repeated aggressor accesses with decoy accesses; the final tREFI contains only decoy accesses. This increases hammering intensity, i.e., activation rates per aggressor, to nearly 6.6× that of prior uniform patterns [48]. Hammering Campaigns. We evaluate GPUThor on four Ampereclass GPUs (A4000, A4500, A5000, A6000), a broader set than prior 1While GeForge [90] claims to perform non-uniform hammering, it has a bit-flip rate (2.2 per bank) similar to GPUHammer (2 per bank) [48] and lower than GPUBreach (5.6 per bank) [50] which both use uniform hammering; it is likely that its access patterns collapse to uniform hammering due to memory request coalescing (C1).
Chris S. Lin, Joyce Qu, Aditya Rajeev, and Gururaj Saileshwar
Table 1: Number of bit flips across GPU Rowhammer attacks. GPUThor induces up to 500× and 23,500× more flips per GB than prior works, GDDRHammer and GPUHammer. Attack
GPU
Flips/Bank
Flips/GB
Ratio
GPUHammer* [48] GeForge* [90] GPUBreach* [50] GDDRHammer* [30]
RTX A6000 RTX A6000 RTX A6000 RTX A6000
2.0 2.2 5.6 94.8
16 18 45 758
1× 1.1× 2.8× 47×
GPUThor (our work)
RTX A6000 RTX A5000 RTX A4500 RTX A4000
14,311 23,597 4,689 4,548
114,488 377,552 75,024 72,768
7,155× 23,597× 4,689× 4,548×
*Bit flip counts for prior works are from their respective papers.
works [30, 48, 50, 90]. Across four banks per GPU with ECC disabled, we observe 72,000–377,000 bit flips per GB, up to 500× higher than GDDRHammer [30] and 23,500× higher than GPUHammer [48]. These flip rates approach the DDR4 bit flip rates with CPU attacks like Blacksmith (550,000 flips/GB) [33], indicating comparable vulnerability. At these bit-flip rates, even SECDED ECC, assumed to be applied at 16-byte granularity in workstation GPUs [83], is insufficient. Across these GPUs (four banks each), at 16-byte granularity, we discover 387 double-bit flips that SECDED ECC can detect but cannot correct (DUE), and 2 triple-bit flips that the ECC can neither detect nor correct, resulting in silent data corruption (SDC); the most vulnerable GPU, the A5000, accounts for 306/387 double-bit flips and 2/2 triple-bit flips. We thus surpass the challenge of defeating ECC (C3) that limits prior GPU Rowhammer attacks. Implications for ECC. We launch campaigns with ECC enabled on the A6000 GPU (our A4000-5000 GPUs are cloud-based, where the provider does not give the option to enable ECC). On the A6000 with ECC enabled, we trigger detectable uncorrectable errors (DUE), i.e., double-bit errors, causing ECC failures and GPU crashes, at an average rate of 1 DUE per hour; on the more vulnerable A5000 GPU, we estimate it would suffer one DUE per 20 minutes on average. Each DUE renders the GPU unusable and requires a GPU reset or a system reboot, enabling denial-of-service attacks, as recovery on cloud systems can take up to 20 minutes per DUE [9]. Crucially, we discover that enabling ECC does not prevent privilege escalation exploits; we observe exploitable multi-bit errors with ECC enabled. Triple-bit errors occurring while ECC was enabled cause the SECDED code to mis-correct, leading to silent data corruption (SDC) that allows the corrupted data to be consumed without triggering a DUE that kills the GPU. Moreover, we discover that even double-bit DUEs are exploitable, since DUEs are serviced lazily in NVIDIA GPUs, leaving a ∼10 ms time window between DUE detection and the GPU being killed, during which the corrupted data is consumed by the attacker’s GPU kernel. Exploiting these properties of SDC and DUEs, we demonstrate that privilege escalation attacks are indeed feasible on an A6000 GPU even with ECC enabled. These results show that NVIDIA-recommended defenses such as ECC are easily bypassed and stronger defenses are needed to mitigate GPU Rowhammer attacks. Contributions. This paper makes the following contributions:
(1) We demonstrate GPUThor, the first non-uniform, high-intensity Rowhammer attack on NVIDIA GPUs, inducing 500× to 23,500× more bit flips than prior works. (2) We reverse-engineer the coalescing behavior of GPU memory accesses and TRR mitigation instances to enable effective non-uniform, multi-tREFI hammering patterns on GPUs. (3) Using GPUThor on GPUs like A4000, A4500, A5000, and A6000, we discover 72,000 to 377,000 bit flips/GB in GDDR6 DRAM with ECC disabled, and hundreds of multi-bit flips (387 double and 2 triple bit flips) uncorrectable by ECC. (4) We demonstrate the first Rowhammer-based denial-of-service and privilege escalation attacks on ECC-protected GPUs. Responsible Disclosure. We disclosed our findings to NVIDIA on 29 April 2026, and also to the major cloud vendors (Google, Microsoft, AWS). NVIDIA requested an embargo until 25th August 2026, when they planned to release a security notice.
2
Background
In this section, we discuss the threat model, the memory system, and the GDDR6 DRAM on NVIDIA GPUs, GPU Rowhammer attacks, and error correction codes (ECC) as a defense on NVIDIA GPUs.
2.1
Threat Model
We assume an unprivileged attacker who can launch CUDA kernels on an NVIDIA GPU with GDDR6 memory, such as A4000–A6000, popularly used in workstations and the cloud. The attacker can co-locate with another victim user on a time-shared GPU in the cloud [22] and try to tamper with its data using Rowhammer, or run from an unprivileged process in a single-tenant setting and attempt privilege escalation to root by tampering GPU Page Tables via Rowhammer [30, 50, 90]. Like prior GPU Rowhammer attacks [30, 48, 50, 90], the attacker can reverse-engineer the GPU virtual-address-to-DRAM bank and row mappings using timing side-channels and hammer neighbors of victim rows. We assume the IOMMU is enabled, similar to prior work [50].
2.2
GPU Memory System
GPU Memory Hierarchy. As shown in Figure 1, NVIDIA GPUs have an array of Streaming Multiprocessors (SMs) that issue memory requests through on-chip L1/L2 caches to a set of on-die memory controllers (MC). Threads within a warp (a group of 32 threads) issue memory instructions in lockstep, and each MC in workstation GPUs (A4000–6000) is connected to independent GDDR6 DRAM channels [35]. The GPU memory system can coalesce multiple requests to the same L1 cacheline within a warp to amortize its cost [62], although coalescing behavior at other levels (L2 cache and memory controller) is undocumented. As we show later (§4), such coalescing has implications for mounting Rowhammer attacks. GDDR6 Organization. As shown in Figure 1, a GDDR6 device is organized as a hierarchy of channels, chips, banks, and rows [35]. Each channel is split into two independent subchannels (Channel A and Channel B), and each chip contains 16 banks; each bank contains thousands of rows of cells storing charge (1s and 0s), and all rows in a bank share a common row buffer. Data is accessed at the granularity of a row: an ACT command opens the addressed row
CCS ’26, November 15–19, 2026, The Hague, Netherlands
GPU Chip Mem MC
MC
MC
MC
SMs
MC
MC
MC
MC
GPU Memory Hierarchy SM L1 Cache L2 Cache MC
GDDR6 DRAM
DRAM Banks
DRAM Chip
Bank Bank
Channel A Channel B
16 banks
GPUThor: Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs
Row
Row Buffer
Figure 1: Memory system in NVIDIA GPUs with GDDR6 DRAM. SMs issue memory requests that are serviced by the L1 or L2 cache or the memory controllers (MC). Each memory controller is connected to a GDDR6 DRAM with two channels, and each DRAM chip has 16 banks; within a bank, DRAM cells are organized as rows, all sharing a common row buffer.
and latches it into the row buffer, column reads/writes operate on the buffered row, and a PRE command precharges the bitlines before another row in the same bank can be activated. Refresh. DRAM cells leak charge and must be periodically refreshed to preserve their contents. Thus, the memory controller issues a REF command once every refresh interval tREFI (≤1.9 𝜇s in GDDR6), which refreshes a subset of rows, so that every row is refreshed within the refresh window tREFW (32 ms in GDDR6) [35]. REF commands also provide the DRAM the time to issue Rowhammer mitigation refreshes [21, 27]; so tREFI is also the typical time unit for constructing Rowhammer access patterns [11, 33, 48].
2.3
CPU Rowhammer Attacks and Defenses
Rowhammer. Rowhammer is a read-disturbance vulnerability in DRAM in which repeatedly activating (“hammering”) a row causes charge leakage in electrically adjacent rows, ultimately flipping bits in those victim cells [43]. The minimum number of activations to a row to induce a bit flip is called the Rowhammer threshold (HCfirst ). Rowhammer access patterns can target a victim row by hammering one (single-sided) or both (double-sided) of its immediate neighbors, also called aggressors. On CPUs, Rowhammer has been used for a variety of exploits, including privilege escalation, sandbox escape, and cryptographic key recovery [8, 11, 23, 33, 34, 80, 88]. Target Row Refresh (TRR). Modern DRAM chips, starting from DDR4, deploy in-DRAM mitigations against Rowhammer, collectively referred to as Target Row Refresh (TRR). TRR samples frequently activated rows and issues a mitigative refresh to their neighbors to reverse the charge leakage in victim rows [21, 27]. However, as TRR trackers have finite capacity, subsequent attacks [21, 33] evaded TRR by hammering aggressor rows interleaved with a larger set of decoy rows, overwhelming the tracker so the aggressors escape mitigation. While TRRespass [21] used uniform patterns that hammered aggressors and decoys at the same rate, Blacksmith [33] developed non-uniform patterns that hammer aggressors at a higher rate than decoys, increasing hammering intensity and flipping bits on a wider range of devices, while also significantly increasing the number of bit flips (up to 550K flips per GB in DDR4 devices [33]). As TRR mitigations align with multiples of tREFI [27], such attacks synchronize the hammering patterns with REF commands [11]. Recent attacks [34, 57] also demonstrate that such non-uniform attack patterns induce bit flips in DDR5 devices with on-die ECC.
CCS ’26, November 15–19, 2026, The Hague, Netherlands
GPUHammer
GDDRHammer
Chris S. Lin, Joyce Qu, Aditya Rajeev, and Gururaj Saileshwar
1 Defeat Coalescing
GeForge
2 Multi-TREFI Hammering
aa11 d1 d2
aa11 a2 d1
d2 d3 d4
aa11 d1 a1
d1 aa11 d1
(a1)α d1 d2
(a1)α d17 d18
(a1)α d65 d66
d81 d82 d83
d3 d4 d5
d2 d3 d4
d5 d6 d7
d1 a1 d1
d6 d7 d8
(a1)β d3 d4
(a1)β d19 d20
(a1)β d67 d68
d84 d85 d86
d6 d7 d8
d5 d6 d7
d8 d9 d10
a1 d1 a1
d9 d10 d11
(a1)γ d5 d6
(a1)γ d21 d22
(a1)γ d69 d70
d87 d88 d89
…
…
…
…
…
…
d15 d2 d3
(a1)δ d15 d16
(a1)δ d31 d32
(a1)δ d79 d80
d102 d103 d104
tREFI1
tREFI2
tREFI5
tREFI6
d13 d14 d15
d13 d14 d15
d15 a11 d1
a1 d1 a1
tREFI1
tREFI1
tREFI1
tREFI2
tREFI3
(a) Prior GPU Rowhammer Patterns
…
…
…
…
(b) Overview of GPUThor (our work)
Figure 2: (a) Prior GPU Rowhammer patterns (𝑎 - aggressor row, 𝑑 - decoy row, aggressor activations in green): GPUHammer and GDDRHammer hammer aggressors uniformly (1-2× activations/tREFI) with single tREFI patterns; GeForge suffers coalescing with 3 tREFI patterns. (b) Overview of GPUThor. It performs non-uniform hammering using 6 tREFI patterns with 6.6× activations per aggressor per tREFI; it avoids coalescing by repeating aggressors across warps and unique cachelines (𝛼, 𝛽, 𝛾, 𝛿).
2.4
GPU Rowhammer Attacks
GPUHammer [48] first showed that GPU Rowhammer attacks are practical on an NVIDIA A6000 GPU with GDDR6 memory. By reverse-engineering the mappings of virtual addresses to GDDR6 banks and rows, it developed multi-thread and multi-warp hammering kernels for hammering GDDR6 memories. As shown in Figure 2 (a), by using 𝑛-sided patterns, i.e., one aggressor and 𝑛 − 1 decoys per tREFI, and uniform hammering (1× aggressor activation per tREFI, same as decoys) like TRRespass [21], it defeated TRR to induce bit flips in GDDR6 memories. GPUHammer used these bit flips to tamper with ML-model weights and degrade the model accuracy. GPUBreach [50] used similar uniform hammering patterns to induce bit flips, and tampered with GPU page table entries to enable system-wide privilege escalation. GDDRHammer [30] and GeForge [90] also demonstrated privilege escalation attacks, with IOMMU disabled. GDDRHammer extends GPUHammer’s uniform hammering from single-sided to double-sided, as shown in Figure 2 (a), providing 34× more bit flips [30]. While it evaluated non-uniform patterns accessing aggressors with higher intensity and multi-tREFI patterns, it found the most bit flips with its uniform pattern (single tREFI, 2× aggressor activations per tREFI). GeForge claims to use a non-uniform hammering pattern that spans three tREFI periods, accessing an aggressor row up to 13 times across 3 tREFIs. However, as it repeats accesses to the same row within a warp, based on our analysis (§4), these accesses get coalesced to a few activations per tREFI, resulting in approximately uniform hammering like GPUHammer. The number of bit flips with GeForge is just 1.1× that of GPUHammer [48] and less than GPUBreach [50], which use uniform hammering. As summarized in Table 1, all four prior GPU Rowhammer attacks use largely uniform hammering patterns and only have tens of bit flips per bank, much lower than prior CPU attacks [28, 33]. Given the low bit-flip rates in GPUs so far, enabling ECC on GPUs has been sufficient to protect against these attacks [30, 48, 50, 90].
2.5
Error Correction Codes on GPUs
ECC. Workstation-class NVIDIA GPUs (e.g., A4000–A6000) with GDDR6 memories support error correction codes (ECC) that provide SECDED (single-error-correct, double-error-detect) level protection [83]. When ECC is enabled, prior analysis [48, 83] suggests
that these GPUs store a 2 B ECC for every 32 B data (a 6.25% memory overhead). Thus, at the granularity of 16 B data, a 1 B SECDED code can correct any single bit flip (single-bit error, SBE) and detect but not correct any two-bit flip (double-bit error, DBE). A DBE results in a detectable, uncorrectable error (DUE), while with ≥ 3 flips, the data can get mis-corrected, causing silent data corruption (SDC). SECDED ECC in CPU DRAM has been shown to be insecure against Rowhammer attacks, with exploits shown on ECC-DIMMs in DDR3 [8] and DDR4 [39], and on DDR5 with on-die ECC [34, 57]. However, thus far, on GDDR6, enabling ECC mitigates all existing GPU Rowhammer attacks. NVIDIA also recommends enabling ECC on GPUs to defend against GPU Rowhammer attacks [61]. Error Management. In the event of a correctable SBE, the NVIDIA GPU silently repairs the SBE and the kernel continues executing; in the background, a counter tracking corrected errors is incremented, which is readable by an unprivileged user process via nvidia-smi. When a DUE is detected on Ampere GPUs, all the running GPU kernels are aborted and the GPU is rendered unusable until it is reset [60]. Additionally, a DUE triggers row remapping, in which the affected row is permanently retired and replaced with a spare row on the next GPU reset; if the pool of spare rows is exhausted, the device raises a row-remapping failure flag, indicating the device qualifies for RMA (return-merchandise-authorization), marking it as defective [60]. This occurs in the event of 9 DUEs in a bank or after 512 DUEs across the entire GPU memory [60].
3
Overview of GPUThor
The goal of GPUThor is to engineer Rowhammer attacks on NVIDIA GPUs with high hammering intensity, capable of producing orders of magnitude more bit flips than prior GPU attacks. We seek to evaluate the real vulnerability of these GPUs and whether ECCbased defenses recommended by NVIDIA [61] are truly secure. We achieve this by enabling non-uniform hammering on GPUs inspired by state-of-the-art CPU Rowhammer attacks [33, 34, 57]. Approach. To mount high-intensity GPU Rowhammer attacks via non-uniform patterns, GPUThor relies on two key building blocks: (1) Defeating GPU memory request coalescing (§4). Since the GPU memory subsystem aggressively coalesces accesses within warps, achieving repeated DRAM activations for the same row is challenging for GPU Rowhammer attacks, unlike on CPUs. We characterize
GPUThor: Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs Uniform
coalescing of memory requests at three levels (within a warp, across warps to the same address, and across warps to different cachelines of the same row) and find that the third regime reliably preserves repeated activations. Therefore, our hammering kernels distribute repeated accesses to an aggressor row across multiple warps and across unique cachelines of that row, enabling repeated DRAM activations and non-uniform hammering. (2) Multi-tREFI non-uniform hammering (§5). While single tREFI hammering enables non-uniform patterns, there is a limit on how much the intensity of aggressors can be increased with a single tREFI pattern, as the placement of decoy rows with respect to TRR sampling instances becomes constrained. To address this, we develop multi-tREFI non-uniform hammering patterns. We characterize the mitigation instances on GDDR6 chips in Ampere GPUs, constructing non-uniform patterns spanning multiple tREFIs and using the resulting bit flip reproducibility as a side channel to learn TRR mitigation frequency. We find that TRR mitigation is performed approximately once every 72 tREFIs, rather than once per tREFI [48, 50]. We enable non-uniform hammering patterns with length up to 6 tREFIs and 6.6 aggressor activations per tREFI. Combining (1) and (2) gives the GPUThor pattern shown in Figure 2 (b): a hammering pattern spanning 6 tREFIs, with the first 5 tREFIs having a total of 40 aggressor activations, and the final tREFI reserved for decoys to overwhelm TRR. Next, we describe these building blocks for our hammering pattern (§4, §5).
Defeating GPU Memory Request Coalescing
In CPU Rowhammer attacks, hammering intensity can be easily increased by adding repeated memory accesses within a tREFI, inducing more activations. However, GPUs can perform memory request coalescing, making this challenging. While NVIDIA documentation [62] suggests that coalescing of requests occurs within warps at the L1 cache level, there is insufficient detail on request coalescing at the L2 cache or activation coalescing at the memory controller, making triggering repeated ACTs difficult. Hence, we first reverse engineer the memory request coalescing on NVIDIA GPUs and then defeat it to craft non-uniform Rowhammer patterns.
4.1
Non-Uniform
3 Warp x 3 Thread
Same Warp
Different Warp
aa d1 d2
aa d1 da2
aa d1 d2
Different Warp and Cachelines aaα d1 d2
d3 d4 d5
d3 d4 d5
ad3 d4 d5
adβ3 d4 d5
d6 d7 d8
d6 d7 d8
d6 d7 d8
d6 d7 d8
Figure 3: Non-uniform patterns (repeated accesses to aggressor rows) used to study request coalescing behavior on GPUs. of 9 accesses in the pattern, and check if the time is consistent with 9 ACTs, similar to the baseline uniform pattern. We measure the time per round for both the uniform patterns and the non-uniform patterns, as shown in Figure 4. To reverse engineer the coalescing behavior within and across warps, we perform the additional accesses to the row 𝑎 either within the same warp as the original access, or all in different warps. We also use addresses from different cachelines, at least 128 B away (𝑎𝛼 , 𝑎 𝛽 , 𝑎𝛾 ) to repeat access to row 𝑎, in same-warp and different-warp configurations, to study hammering of unique cachelines in a row.
4.2
Coalescing Within a Warp
Figure 4 shows the time per round for the non-uniform patterns hammering additional aggressor rows, with intensity 2× and 3× within the same warp, compared to the baseline uniform hammering (1× intensity). While the uniform pattern has a time per round of 484 ns (for 9 ACTs), the non-uniform patterns with additional accesses in the same warp have a lower time per round of 469 ns, indicating that the pattern did not generate 9 ACTs. This is regardless of whether the additional accesses occur to the same cacheline or different cachelines in the same row. This suggests that the additional requests do not induce unique ACTs to row 𝑎, and they likely get coalesced at the memory controller. Observation 1. Repeated requests to a row within a warp get coalesced at the memory controller, and do not generate unique ACTs, and are unsuitable for non-uniform hammering.
Reverse Engineering Approach
For our experiments, we reverse engineer the virtual address to DRAM bank and row mappings, similar to prior work, GPUHammer [48]. For all of our accesses, we use an ld.volatile followed by discard to ensure accesses skip the L1 and L2 caches respectively. We use an A5000 GPU for our experiments, but we validate that the memory access coalescing behavior is similar across GPUs, including A4000-A6000 (Ampere, GDDR6), L4 (Ada, GDDR6), and A30 (Ampere, HBM2). As our baseline, we use a uniform 9-sided hammering pattern, similar to prior work GPUHammer [48], consisting of 3 Warps × 3 Threads, that accesses 9 unique rows: 1 aggressor (𝑎) and 8 decoy rows (𝑑 1 -𝑑 8 ). We then generate non-uniform patterns with 2× and 3× intensity for row 𝑎, by replacing one or two decoy rows in the pattern with repeated aggressor row (𝑎) accesses, as shown in Figure 3. To validate whether the non-uniform patterns produce 2× or 3× activations for the repeated aggressor row (𝑎), we measure the time per round for each pattern, i.e., the time to complete one round
Time per Round (ns)
4
CCS ’26, November 15–19, 2026, The Hague, Netherlands
600
573
Baseline: 484 ns 2x Intensity 3x Intensity
550 500
502 469
469
469
469
484
484
450 400
Same Warp Same Cacheline
Same Warp Diff Cacheline
Diff Warp Same Cacheline
Configurations
Diff Warp Diff Cacheline
Figure 4: Average time for a round of hammering with 2 − 3× repeated accesses to an aggressor row, accessed within or across warps, using addresses from the same or different cachelines in the row. The baseline is the time for a uniform pattern hammering 9 rows without repetition.
CCS ’26, November 15–19, 2026, The Hague, Netherlands
4.3
Repeated Requests Across Warps
In Figure 4, in non-uniform patterns where the aggressor row is repeatedly hammered from different warps, we see a timing spike when the repeated access is from the same cacheline, jumping to 502 ns and 573 ns per round for 2× and 3× intensity hammering, from the baseline 484 ns. This is because discard from the first warp, which evicts the cacheline from the L2 cache, interferes with the repeated request for the cacheline from the second warp, which causes the latency of these accesses to increase far beyond the ACT latency. Thus, while repeated accesses across warps may not get coalesced, the timing spike due to the discard’s contention across warps can cause the synchronization of the pattern with tREFI to be disturbed, making it unsuitable for hammering. In contrast, when repeated accesses from different warps are to different cachelines of the row, 128 B apart, the timings are similar to those of the uniform hammering (484 ns), ensuring that there is no coalescing of requests across warps. This indicates that these non-uniform patterns likely have the same number of ACTs in total as the uniform hammering pattern, and additional ACTs for the aggressor row, 𝑎. Across different warp/thread configurations, the time per round is closest to the baseline when the repeated accesses across warps are to different cachelines, even when it does not exactly match the baseline, indicating the ACTs are preserved. Observation 2. Repeated requests from different warps for different cachelines in a row are not coalesced and generate unique ACTs, suitable for non-uniform hammering.
4.4
Non-Uniform Hammering in a Single tREFI
Using the non-uniform pattern from Section 4.3, we perform hammering campaigns. As a baseline, we use a 24-sided uniform pattern (8 warps × 3 threads) that has 1 aggressor and 23 decoy rows accessed uniformly within a tREFI, like GPUHammer [48]: this overwhelms the 16-entry TRR sampler [48]. We construct non-uniform single-tREFI patterns with 2×, 3×, and 4× intensity by repeating aggressor accesses across different warps using distinct cachelines. Table 2 reports bit flips with these non-uniform patterns on an A5000 GPU across four random DRAM banks. The 1× uniform baseline (GPUHammer) induces, on average, only 21 bit flips, while the 2× non-uniform pattern yields an average of 32.5 bit flips, a 1.5× increase. However, higher intensity patterns (3× and 4×) show a decrease in flips compared to the 2× patterns. This suggests that while non-uniform hammering with higher intensity can improve bit flips, scaling beyond 2× intensity within a single tREFI is challenging. As aggressor intensity increases, the positions of decoys become constrained within the tREFI window, reducing their chance of being sampled by TRR and their likelihood of fooling TRR. To alleviate this, we explore non-uniform patterns spanning multiple tREFIs. Observation 3. Non-uniform single-tREFI hammering patterns increase the number of bit flips by 1.5× by increasing intensity. But successful single-tREFI patterns are limited to 2× intensity, prompting the exploration of multi-tREFI patterns.
Chris S. Lin, Joyce Qu, Aditya Rajeev, and Gururaj Saileshwar
Table 2: Number of bit flips on an A5000 GPU using nonuniform, single-tREFI patterns with 2×, 3× and 4× intensity, compared to the baseline 1× intensity uniform pattern [48]. Baseline [48]
Non-Uniform, Single-tREFI
1×
2×
3×
4×
Bank 1 Bank 2 Bank 3 Bank 4
22 15 27 20
29 25 49 27
20 16 35 23
12 11 27 15
Average
21
32.5 (1.5×)
23.5 (1.1×)
16.3 (0.8×)
5
Multi-tREFI Hammering on GPUs
To overcome the limitation of single-tREFI patterns, we investigate non-uniform hammering across multiple tREFIs. Our goal is to increase aggressor intensity while continuing to evade TRR. For this, using a known bit flip in Table 2, we try to reproduce it using multitREFI patterns while systematically exploring the design space of non-uniform patterns. First, keeping aggressor activation counts fixed, we evaluate whether spreading them out over multiple tREFIs retains the bit flip (§5.1). Next, we replace decoys with aggressor activations to study the potential to increase intensity (§5.2).
5.1
Increasing Pattern Lengths to 𝑛 tREFIs
We reverse-engineer TRR mitigation frequency using non-uniform multi-tREFI patterns by increasing pattern lengths from 1 to 𝑛 tREFIs and measuring the flip probability for the pattern over 50 trials, defined as the percentage of trials in which the hammering pattern is able to successfully reproduce a given bit flip. As shown in Figure 5, our 𝑛-tREFI hammering pattern consists of an aggressor receiving 𝑛 ACTs in a round (aggressor intensity of 𝑛) and the remaining ACTs target randomly chosen decoy rows (one ACT per decoy). We keep aggressor intensity per tREFI constant across pattern lengths, ensuring the total aggressor activations remain the same. After one round of 𝑛-tREFIs, the pattern is synchronized with the REF command via inserted delays. Since TRR sampling instances are unknown, we sweep the starting offset of aggressor activations within each round: for a round with 𝑁 ACTs and aggressor intensity 𝑛, we vary the offset from 0 to 𝑁 −𝑛. We also study higher aggressor intensities (2× to 4× per tREFI) in these multi-tREFI patterns. Length 2 TREFI 2 TREFI 3 TREFI 3 TREFI
Offset Intensity Hammering Pattern (N ACTs per Round) 0
…
N-2
Sync
…
2
0
3
N-3
3
…
…
2
… Sync
Next Round
…
TREFI
Decoys
Aggressor
Figure 5: Hammering non-uniform patterns as the length (𝑛-tREFIs) increases, keeping intensity per tREFI fixed. Figure 6 shows the flip probability for the same bit flip as we increase the pattern length from 1-36 tREFIs. The flip is reliably
GPUThor: Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs
reproduced for pattern lengths of 2, 3, 4, 6, 8, 9, 12, 18, 24, and 36 tREFIs. For pattern lengths beyond 36 tREFIs, bit flips are no longer observed reliably (we observed a bit flip just once for a 48 and 72 tREFI pattern). Combined with the observation that a majority of the successful pattern lengths divide 72, this suggests that TRR mitigations likely operate every 72 tREFIs in GDDR6. Notably, higher aggressor intensities (2-4× per tREFI), which fail to reliably produce this bit flip for single-tREFI patterns, consistently reproduce it in multi-tREFI patterns. This shows that non-uniform multi-tREFI patterns can trigger bit flips at higher intensities.
80
Intensity per tREFI 2x
3x
4x
60 40 20 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Pattern Length (Number of tREFIs)
24
27
36
Figure 6: Bit flip probability as pattern length increases to multiple tREFIs. Bit flips are most reproducible (more than 10% flip probability) at pattern lengths of 3, 4, 6, 9, 18, and 24 tREFIs; Bit flips stop reliably appearing after 36 tREFIs.
5.2
across the pattern, for the reliable multi-tREFI pattern lengths (e.g., lengths that divide 72 tREFI and had >10% flip probability in Figure 6). Shorter pattern lengths, such as 3 tREFI patterns, only trigger bit flips up to an intensity of 5 ACTs per tREFI. On the other hand, longer pattern lengths such as 24 tREFI patterns trigger bit flips up to an intensity of 7 ACTs per tREFI. Across all pattern lengths, the flip probability generally declines once ACT/tREFI reaches higher intensities. This is because as the number of aggressor activations increases, the number of instances when decoy rows get sampled that help to evict the aggressor from the TRR sampler decreases. Shorter patterns are able to maintain higher flip probability for bit flips at similar intensity, since shorter patterns (e.g., 6 tREFI pattern) have a higher chance of alignment with a TRR mitigation instance (every 72 tREFIs), compared to longer patterns (e.g., 24 tREFI). We desire both high intensity and flip probability to be able to trigger a larger number of bit flips in Rowhammer campaigns. Hence, for GPUThor, we choose a 6-tREFI pattern with an intensity of 6.6 ACTs per tREFI as our attack pattern.
Flip Probability (%)
Flip Probability (%)
Observation 4. Non-uniform multi-tREFI hammering reliably triggers bit flips at higher intensities of at least 4× per tREFI. TRR mitigations likely apply every 72 tREFIs, suggesting that multi-tREFI patterns that divide 72 can reliably trigger bit flips.
CCS ’26, November 15–19, 2026, The Hague, Netherlands
40.0% 30.0% 20.0% 10.0% 0.0%
3-TREFI 4-TREFI 6-TREFI 9-TREFI 18-TREFI 24-TREFI
2
3
4 5 6 7 Aggressor Intensity (ACTs/tREFI)
8
Figure 7: Multi-tREFI hammering with increasing aggressor intensity (ACTs per tREFI) for different pattern lengths (3, 4, 6, 9, 18, 24 tREFI patterns). Our patterns reproducibly trigger bit flips with intensity of up to 7 ACTs per tREFI.
Increasing Intensity for 𝑛 tREFI Patterns
Having identified multi-tREFI patterns that reliably reproduce bit flips (patterns where lengths divide 72), we study how far we can increase aggressor intensity while maintaining reproducibility. Approach. We start with the more reproducible multi-tREFI patterns that divide 72 tREFI (i.e., 3, 4, 6, 9, 18, and 24 tREFIs long) with a baseline aggressor intensity of 2× ACTs per tREFI, and progressively increase intensity by replacing decoy accesses with aggressor accesses. Each step increases the number of aggressor activations, while ensuring no more than one aggressor ACT per warp, to avoid coalescing as discussed in §4. Since each victim row can have two aggressor rows surrounding it, we first replace decoys greedily with just a repeated single-sided aggressor, generating patterns that increase the intensity from 1 to 7 ACTs per tREFI. Once all the warps have at least one aggressor, we follow the same procedure to add the other-side aggressor to these warps to generate patterns with intensity of 8 to 15 ACTs per tREFI. For a given pattern, after assigning aggressor activations, all the remaining activations are chosen to target unique decoy rows. For each pattern, we measure its flip probability to identify the higher-intensity patterns that reliably induce bit flips. Results. Figure 7 shows the flip probability across 100 trials for a bit flip as the aggressor intensity increases from 2 to 15 ACTs per tREFI
Observation 5. The 6 tREFI pattern triggers flips at high aggressor intensity (6.6 ACTs per tREFI) reproducibly, making it suitable to trigger a larger number of flips in campaigns. Single-sided vs Double-Sided. We observe that even when using two-sided aggressors in our pattern, the combined intensity of aggressors that triggers flips remains ≤ 7 ACTs per tREFI. This limit persists regardless of whether we activate only the single-sided aggressor throughout, or equally divide the activations between the two aggressor rows (double-sided). Thus, the maximum activation intensity appears to be constrained by the GDDR6 TRR implementation. A plausible explanation is that in this TRR implementation, a victim row is definitively refreshed when the combined activations from both adjacent aggressors exceed a threshold: e.g., one-third of total activations within the 72-tREFI mitigation window. Similar TRR mechanisms have been observed in other GPU memories like HBM2 [64]. Thus, distributing activations across one or both aggressors does not increase the achievable intensity, indicating that single-sided and double-sided patterns offer similar effectiveness under our high-intensity, non-uniform, multi-tREFI hammering.
CCS ’26, November 15–19, 2026, The Hague, Netherlands
5.3
Chris S. Lin, Joyce Qu, Aditya Rajeev, and Gururaj Saileshwar
GPUThor: Putting It Together
Figure 8 shows the non-uniform, multi-tREFI pattern we use in GPUThor to enable high-intensity Rowhammer attacks on GPUs. The non-uniform hammering uses repeated aggressor activations in distinct warps and uses distinct cachelines within a tREFI to defeat request coalescing. The pattern spans 6 tREFIs, using an aggressor intensity of 6.6 ACTs/tREFI across the entire pattern. The first 5 tREFIs contain repeated aggressor activations (one per warp) and decoy activations, and the last tREFI only contains unique decoy row activations. We observe GPUThor achieves up to 110K aggressor ACTs per tREFW, which is 6.6× more than prior uniform hammering patterns with GPUHammer [48].
1st TREFI … …
a1 Warp 1
5th TREFI …
…
a1 Warp 8
8 Aggressors ACTs
a1
…
6th TREFI … …
a1
Warp 8 Warp 1 Decoys
Warp 1
Warp 8
All Decoys
6.6 ACTs per TREFI for Aggressors in Pattern
Figure 8: GPUThor Hammering Pattern.
6
Results
We evaluate GPUThor on a broad set of NVIDIA GPUs with GDDR6 memories to study its bit-flip behaviors and real-world implications. Our evaluations focus on answering the following questions: (1) Does GPUThor induce significantly more bit flips than prior attacks on a wide range of NVIDIA GPUs? (§6.2) (2) Do the increased bit flips with GPUThor reduce the time needed for GPU Rowhammer-based privilege-escalation exploits? (§6.3) (3) Does GPUThor induce multi-bit flips that can potentially defeat ECC on GDDR6 based NVIDIA GPUs? (§6.4) (4) Can GPUThor trigger exploits on GPUs despite NVIDIA-recommended mitigations like ECC being enabled? (§7)
6.1
Experimental Setup
Target GPUs. We evaluate GPUThor across four Ampere-class NVIDIA GPUs: the RTX A4000, A4500, A5000, and A6000, spanning the GA102 and GA104 architectures with 16–48 GB GDDR6 memory. The RTX A6000 is hosted locally, while the A4000, A4500, and A5000 are accessed on the cloud. Our A6000 uses Samsung GDDR6, as confirmed using LACT [31]; the cloud GPUs do not expose the low-level permissions required to identify the memory vendor. All experiments in §6 are conducted with ECC disabled, reflecting the default in several cloud GPUs (our cloud GPUs do not enable ECC by default, nor provide us the permissions to enable ECC); we enable ECC for the local A6000 for evaluations in Section 7. We use Ubuntu 22.04 with IOMMU enabled, like prior work [50]. Recovering Address-to-Row Mappings. Like GPUHammer [48], we reverse-engineer the GPU virtual-address-to-DRAM bank and row mapping in two steps. First, we use timing side-channels on row-buffer conflicts [48, 68] to recover addresses that map to the same bank. Within each bank, we identify addresses mapping to the same row based on row-buffer-hit timing and identify unique
addresses mapping to the same bank and consecutive rows. We use this set of addresses, called the row set, for hammering campaigns. Hammering Configuration. Our hammering kernels use 8 warps × 3 threads, with each thread hammering one row in a tREFI like GPUHammer [48]; the pattern synchronizes with REF every 𝑛−tREFI through added delays. We introduce an outer loop for multi-tREFI patterns to hammer a different schedule of activations every tREFI for GPUThor’s non-uniform patterns. Our hammering campaigns sequentially select each row in the bank as aggressor, and hammer using four victim/attacker data patterns: 0xff/00, 0x00/ff, 0xaa/55, 0x55/aa. Our hammering campaigns last for 24 hours/bank on each GPU and we hammer four banks per GPU. Exploits. As a proof-of-concept for exploitation with our bit flips, we use the GPU page-table corruption exploit similar to prior works [30, 50, 90]. For this, we use the open-sourced GPUBreach exploit code [49]. Here, the attacker massages PTEs into target DRAM rows, hammers neighboring aggressors to flip the pageframe-number (PFN) bits of a PTE, and ensures the tampered PTE maps to another PTE via an additional massaging step, to gain arbitrary read/write privileges to the entire memory. For the ECCenabled settings, we describe our exploit methodology in §8.
6.2
Bit Flip Characterization
Table 3 shows the results of our hammering campaigns on 4 GPUs (A4000-A6000) targeting 4 DRAM banks each. While GPUHammer [48] produces 19 to 658 bit flips on these GPUs, GPUThor yields 18,000 to 94,000 unique bit flips. GPUThor achieves 143× (A5000) to 2,602× (A6000) more bit flips compared to GPUHammer. Across the four GPUs, we observe that the A5000 GPU has the highest vulnerability levels, resulting in 377K bit flips per GB. The A6000 GPU has the second-highest vulnerability level, with 114K bit flips per GB. The A4500 and A4000 have the lowest vulnerability levels with 75K and 72K flips per GB. The bit flip rates with the GDDR6 DRAM on the A5000 GPU are close to the worst-case vulnerability in DDR4 DRAM with state-of-the-art CPU attacks like Blacksmith (550K flips per GB) [33], indicating that our nonuniform GPU Rowhammer attacks produce similar worst-case bit flip rates as the best CPU Rowhammer attacks. On the A5000, the most vulnerable GPU, we observe 3,584 flips per hour (one per second) for the best data pattern with GPUThor. This rate, achieved by hammering a single bank at a time, is almost 180× faster than the prior best of 20 flips per hour with GDDRHammer [30] and multi-bank hammering (6 banks hammered in parallel). Across GDDR6 banks of a GPU, the vulnerability levels are similar: e.g., on the A5000, the average (23597 flips per bank) is similar to that of the most vulnerable bank (31797 flips). Across the GPUs, we observe an average of 0.15-0.76 flips per row. This makes multiple flips per row and cacheline a common occurrence, and multi-bit flips capable of defeating ECC likely (§6.4). Across the GPUs, we also measure the minimum activation count to trigger a bit flip (HCfirst ), by re-hammering the bit flips from GPUHammer patterns with activation counts decremented by 100 until the flips stop appearing. All of the GPUs have HCfirst values between 12.3K and 15.8K, with no direct correlation between the GPU’s overall vulnerability and its HCfirst value.
GPUThor: Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs
CCS ’26, November 15–19, 2026, The Hague, Netherlands
Table 3: Rowhammer bit flips from campaigns on A4000, A4500, A5000 and A6000, hammering 4 banks each (24 hours / bank). Our campaigns use GPUThor and prior work, GPUHammer [48]. GPUs
GPUHammer [48] Total Unique Flips
Avg. Flip / Row
Avg. Flip / Bank
Avg. Flip / GB
Flip / Hour (Best Data Pattern)
Min. HCfirst
57247 (2602×) 94389 (143×) 18756 (987×) 18192 (790×)
0.22 0.76 0.15 0.15
14311 23597 4689 4548
114K 377K 75K 72K
1501 3584 882 838
12.3K 15.8K 13.6K 12.4K
Name
Arch
VRAM
Rows / Bank
Total Unique Flips
A6000 A5000 A4500 A4000
GA102 GA102 GA102 GA104
48GB GDDR6 24GB GDDR6 20GB GDDR6 16GB GDDR6
64K 32K 32K 32K
22 658 19 23
GPUThor (Our Work)
Table 4: Time to mount privilege-escalation exploit using GPUThor compared to GPUHammer [48]. GPUHammer [48]
6.3
GPUThor (our work)
GPU
Row Set (min)
Bit-Flip Discovery (min)
Privilege Escalation (min)
Total (min)
Row Set (min)
Bit-Flip Discovery (min)
Privilege Escalation (min)
Total (min)
A6000 A5000 A4500 A4000
90 3.1 8.8 10
1223.6 3.6 237.5 403.8
0.3 0.2 0.2 0.2
1313.9 6.9 246.6 414.0
0.5 0.3 0.5 0.4
0.3 0.1 0.5 0.6
0.3 0.2 0.2 0.2
1.1 0.6 1.2 1.2
Time to Exploit
As GPUThor discovers bit flips significantly faster than prior work [48], it directly reduces end-to-end exploit time. We demonstrate this using a privilege-escalation exploit that corrupts GPU PTEs via Rowhammer, following prior attacks [30, 50, 90]. Setup. We implement a privilege escalation exploit, similar to GPUBreach [50], using their exploit code [49], replacing the default uniform hammering kernel with GPUThor’s non-uniform hammering. We evaluate the exploit using both GPUHammer [48] and GPUThor hammering, and measure the total time including the offline and online phases of the exploit. The offline phase includes the discovery of the row-set (addresses mapping to rows of the same bank), and the hammering campaign to find exploitable bit flips; the online phase includes massaging the PTE entries to vulnerable rows and hammering the neighbors to escalate privileges [50]. Results. Table 4 shows the total exploit time across four GPUs. With GPUHammer, the end-to-end exploit can take up to several hours (21.9 hours on A6000 and 7 hours on A4000). The A5000, the most vulnerable GPU, is the exception where the exploit succeeds in 6.9 minutes. The main bottleneck in the exploit is the offline phase, particularly the exploitable bit-flip discovery, which takes almost 20.4 and 6.7 hours on the A6000 and A4000. This is because for the exploit to succeed [50], we need the bit flips to be at specific offsets (25 bits of the page frame number in the 8 B PTE entry). This takes only 3.6 minutes on the A5000, the most vulnerable GPU. In contrast, GPUThor reduces bit-flip discovery time to less than a minute (0.1–0.6 minutes), bringing the total exploit time down to 0.6–1.2 minutes across all the GPUs (10× to 1200× lower than GPUHammer). This is due to the significantly higher rate of exploitable bit flips discovered by GPUThor. This also makes rowset discovery time faster, as GPUThor requires a smaller row-set (tens of rows) given the higher spatial density of its discovered bit flips, compared to GPUHammer that requires larger row sets (tens of thousands of rows across multiple banks).
The online phase (PTE massaging and final hammering) remains unchanged in GPUHammer and GPUThor (0.2–0.3 minutes) and is a small fraction of the total runtime.
6.4
Multi-Bit Flips
Beyond increasing the number of bit flips compared to prior works [30, 48, 50, 90], GPUThor also provides bit flips with higher spatial density. Table 5 quantifies the number of multi-bit flips observed in GPUThor’s hammering campaigns across GPUs at 8 B, 16 B and 32 B granularity. These are based on the potential ECC code granularity in GDDR GPUs that store 2 B ECC per 32 B data [83]. At 16 B and 32 B granularities, we observe double-bit flips on all GPUs, with counts increasing at larger granularities. This is most pronounced on the A5000 and A6000, with up to 137 and 26 double-bit flips per bank at 16 B granularity (276 and 54 within 32 B), respectively. The A4000 and A4500 exhibit fewer multi-bit flips, consistent with their lower overall vulnerability. These double-bit flips can potentially result in detectable, uncorrectable errors (DUE) with SECDED ECC, causing data loss or denial of service. The A5000 also exhibits two triple-bit flips at a 16 B granularity and four at a 32 B granularity (two of them also fall within an 8 B region). These are particularly concerning, as they exceed both the correction and detection capability of SECDED ECC on GDDRbased GPUs, resulting in silent data corruption (SDC). Next, we evaluate implications of GPUThor’s bit flips on ECC-enabled GPUs.
7
Implications for ECC Protections on GPUs
As GPUThor can induce multi-bit flips beyond ECC’s correction capability, we analyze how NVIDIA’s ECC behaves under multi-bit flips by running Rowhammer campaigns using GPUThor with ECC enabled (§7.1), derive insights on NVIDIA’s ECC algorithm (§7.2) and discuss potential exploits on ECC-protected GPUs (§7.3).
CCS ’26, November 15–19, 2026, The Hague, Netherlands
Chris S. Lin, Joyce Qu, Aditya Rajeev, and Gururaj Saileshwar
Table 5: Multi-bit flips across A4000, A4500, A5000, A6000 at 8-, 16- and 32-byte granularity. All the GPUs have double bit flips, while the A5000 also has triple bit flips. Double Bit Flips
Bank 1 Bank 2 Bank 3 Bank 4
7.1
Triple Bit Flips
A4000 16B 32B
A4500 16B 32B
A5000 16B 32B
A6000 16B 32B
8B
A5000 16B 32B
6 2 4 1
5 4 6
73 40 137 56
26 15 7 5
1 1 -
1 1 -
13 6 10 3
6 11 10
138 79 276 128
54 27 11 10
2 2 -
Reverse Engineering ECC on NVIDIA GPUs
NVIDIA GPUs use an undisclosed ECC algorithm. Prior work [83] has speculated that GDDR6 NVIDIA GPUs provision 2B of sideband ECC per 32B data access, resulting in a 6.25% memory storage overhead. However, reverse-engineering the exact ECC implementation on GDDR memories is difficult without tools like logic analyzers and FPGA-based testbeds used in prior CPU DRAM studies [8, 39]. Thus, we hammer blindly with ECC enabled and leverage side-channels to infer the ECC scheme details. Approach. We enable ECC on our GPUs and execute hammering campaigns with GPUThor. In the event of correctable errors, NVIDIA GPUs do not provide logs specifying the bit locations of corrected flips. Moreover, we observe that NVIDIA GPUs do not exhibit any timing variations on memory reads when the ECC corrects a bit flip, unlike similar timing side-channels on CPUs observed in prior works [8, 39]. Instead, we discover two new side channels: (1) the number of corrected errors reported by nvidia-smi in the “Volatile DRAM Correctable” counter, and (2) a timing variation in the completion time of the GPU kernel, due to the delivery of these ECC counter updates to the CPU driver. As shown in Figure 9, the kernel completion time shows an increase from 4.5 ms→7.6 ms when an error is corrected during the kernel execution. These kernel execution times are much less than the latency to probe nvidia-smi (178 ms); hence, we use the kernel completion-time side-channel in our campaigns to detect correctable errors.
Latency (ms)
Timing side-channel
7.2
Insights on NVIDIA ECC Implementation
In our campaign with ECC enabled on the A6000, we observe 94 DUEs and 1 SDC across four banks. We derive several insights about the NVIDIA ECC based on this. ECC Granularity. Across the campaign, all the DUEs have at least two bits flipped within a 32 B granularity, indicating that NVIDIA’s ECC code is calculated at the granularity of ≤32 B. Additionally, we observe some instances of two bit flips within 32 B data that are both corrected simultaneously, i.e., one bit flip per 16 B on average that is correctable. This suggests that NVIDIA uses a SECDED ECC scheme where 1 B ECC code protects 16 B of data. Given that each 32 B data stores a 2 B ECC, there are two 16 B non-contiguous chunks of data, each protected by a 1 B SECDED ECC. Observation 6. NVIDIA ECC protects 32 B data with a 2×1 B SECDED code, where each 1 B ECC provides SECDED protection for 16 B of data (non-contiguous halves of 32 B data).
150 100
0
Campaign Setup. The A5000 GPU, which is the most vulnerable in our test set, is cloud-based (as are the A4000 and A4500), where the cloud provider does not expose permissions to enable ECC. Thus, we only run campaigns with ECC enabled on the local A6000 GPU. We run a campaign on 4 banks, where hammering a full bank with ECC enabled to find DUEs takes ∼1 day per bank per data pattern. For a campaign that also identifies the bit locations of flips in each DUE and corrected SBE via bit masking, it takes ∼1.5 days per bank per data pattern.
178
200
50
a GPU reset to restart our campaigns. DUEs also trigger a rowremapping on Ampere GPUs [60], which remaps the row where the DUE is detected to a spare row in the bank (up to 8 remaps per bank permitted). In our campaigns, we flash the GPU InfoRom with nvflash [87] before a GPU reset to skip the row-remapping. We discuss later (§8) how an unprivileged attacker can work around row-remapping for exploits with uncorrectable bit flips. When we detect a correctable error or DUE, to recover the exact bit location within a row of the bit flip, we apply masking [8, 12, 39] similar to prior works. Here, we invert a selected bit in the row in the expected direction of a flip, and try to re-trigger the error by hammering; if it fails to trigger, then we know the bit flip location. If a triple bit flip is triggered, it surpasses the ECC’s detection capabilities and leads to a Silent Data Corruption (SDC); here we observe multiple bits remain flipped even after our side-channel indicates an error was corrected and the kernel does not crash.
4.5
7.6
Kernel Elapsed Time (No Errors)
Kernel Elapsed Time (Error Corrected)
nvidia-smi
Figure 9: Side channels allowing detection of corrected errors: kernel completion time increases when an error is corrected during execution (4.5 ms → 7.6 ms); nvidia-smi that also reports corrected error counts has higher latency (178 ms). In the event of detectable but uncorrectable errors (DUE), the CUDA kernel crashes and subsequently requires a GPU reset: fortunately, the GPU driver logs the byte location of such errors to syslog, allowing us to infer their locations. In such events, we use
Miscorrection on DUEs. On a DUE, along with the two bits that flip due to Rowhammer (identified by masking those bits and trying to re-trigger them), we observe additional bits may flip within 32 B data, indicating the ECC incorrectly attempts correction and miscorrects the data even on a DUE. Across the 94 DUEs observed in the hammered banks, each resulted in 2-13 flips (∼5 on average). In a given DUE, the extra flips due to miscorrection always occur at fixed locations relative to the location of the rowhammer-induced flips, and are independent of the data values. Typically, the original Rowhammer bit flips are preserved in the miscorrected data. Delayed DUE Handling by Driver. Most importantly, on a DUE, the miscorrected data remains accessible from the GPU kernel for
GPUThor: Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs
up to 10 ms. Although no new CUDA API calls can be triggered from the CPU, the corrupted data can be consumed by the CUDA kernel on the GPU and used for page table translations if a GPU PTE is corrupted. We use this insight for our DUE-based privilege escalation exploit in §8. The GPU context remains accessible to CUDA kernels for ∼10 ms after the DUE, after which all the kernels are terminated, and the GPU is unusable until a full reset. Observation 7. After a DUE, GPU kernels remain alive for 10 ms and can consume the corrupted data or illegally access data outside their process through corrupted PTEs. Triple-Bit Error inducing SDC. While a two-bit flip yields a DUE, we also found a triple-bit flip within the ECC granularity that gets mis-corrected without crashing the kernel, resulting in an SDC. A three-bit error is known to exceed the detection and correction capacity of a SECDED-based Hamming code, so its syndrome aliases to that of a single-bit error [26]. We observe NVIDIA ECC exhibits similar behavior, where it flags a triple-bit flip as a correctable error, mis-corrects it to end up flipping a fourth bit whose location is fixed deterministically based on the location of the other three flips. Since the triple-bit flip miscorrections do not crash the kernel, these enable privilege escalation exploits [50], as shown in §8.
8 Privilege Escalation Exploit with ECC Enabled 8.1 Overview We demonstrate a privilege-escalation exploit on ECC-enabled GPUs, building on prior exploits [30, 50, 90] through Observation 7 and Observation 8. Prior attacks [30, 50, 90] follow three key steps: (1) massage page tables (PTs) to vulnerable rows, (2) induce bit flips by hammering neighbors, and (3) massage a new PT at the destination of the corrupted PT entries to control GPU page tables and escalate privileges by accessing and tampering with privileged CPU memory. However, with ECC enabled, step (3) can be infeasible as GPU memory allocations, needed for massaging GPU PTs, are not permitted after a flip in the case of a DUE. Thus, for our exploit, we pre-place a PT into a location predicted to be the destination of a corrupted PT (Figure 10). After a successful PT corruption, this allows us to (i) access and modify the pre-placed PTE, altering it to point to CPU memory using the Aperture bits (“A” in Figure 11) and (ii) use it to tamper with privileged CPU memory (within 10 ms before the GPU kernel terminates in the case of a DUE), enabling privilege escalation. Our threat model assumes a single-tenant setting for the A6000 with ECC enabled.
Abusing Return Merchandise Authorization (RMA) Policy. NVIDIA GPUs have an RMA policy [60] for defective products. A GPU becomes RMA eligible when row-remapping fails: each GPU bank has 8 spare rows and each DUE triggers a row remap. If any bank experiences more than 8 DUEs, a row-remapping failure flag is set (visible via nvidia-smi), making the GPU eligible for RMA. From Table 5, 2 of our 4 GPUs meet this condition, indicating that GPUThor can be used by malicious customers to trigger RMA eligibility and request a free GPU replacement. In our ECC-enabled campaign, the A6000 has the row-remapping failure flag set after the 9th DUE, within 18 hours. This poses a risk of warranty abuse by GPU owners, with potential financial implications for GPU vendors. Privilege Escalation under ECC Miscorrection. Observation 7 and Observation 8 suggest that ECC miscorrections on DUEs and SDCs can both be exploited for potential privilege escalation attacks. We discuss this in more detail in §8.
GPUBreach: ECC-ON w/ DUE
1. Corrupt PTE
1. Massage PT Region Data Page PTE
PTE
Pr ed ic
Data Page
Exploits on ECC-Enabled GPUs
Denial of Service (DoS) Exploits. All our GPUs belong to the GA10x architecture, which does not support Error Containment [60]. Thus, a single DUE kills all running processes on the GPU, requiring a full GPU reset to recover, resulting in a DoS. On the A6000 with ECC enabled, we can trigger, on average, 23.5 DUEs per bank within one day of hammering (∼1 DUE / hour). Since GPUs in the cloud have been shown to have a Mean Time To Repair (MTTR) of 0.3 hours [9] to reset the entire node, this reduces the GPU node’s availability under a DoS attack by 22.7% (∼5.5 hours of downtime per day) and causes data loss due to frequent crashes.
GPUBreach: ECC-Off
Data Page
Observation 8. A triple-bit flip within the ECC granularity can induce Silent Data Corruption under NVIDIA’s ECC.
7.3
CCS ’26, November 15–19, 2026, The Hague, Netherlands
2. Massage PT Region
te d
Data PT Page Region
2. Corrupt PTE (DBE) Data Page
Data Page PTE
PTE
Data PT Page Region
Data PT Page Region
Figure 10: Privilege escalation exploit with GPUBreach [50] when ECC is enabled using DUEs. We predict the corrupted PTE value and massage a PT into the predicted location in advance, enabling the exploit within 10 ms of a DUE.
8.2
Offline Profiling for DUEs and SDCs
We target 2 MB PTEs for corruption with bit flips (Figure 11). In these PTEs, a multi-bit flip is exploitable only if (1) some of its bit flips reside in the Page Frame Number (PFN) region of the PTE (25 out of 128 bits) and (2) the tampered PFN ends up in useraccessible memory. An additional challenge is that miscorrections from either a DUE or an SDC can flip additional bits along with the Rowhammer-induced errors. While the original flip locations can be identified easily (Section 7.1), the miscorrections on DUEs are hard to predict. Fortunately, out of the 94 DUEs we found in Section 7.2, 26 have flips within the PFN suitable for our exploit. The discovered SDC also has exploitable flips within the PFN. To practically develop an exploit, we need to overcome the remapping of rows on DUEs or induce an exploitable DUE or SDC without triggering the row-remapper. We develop two approaches for this.
CCS ’26, November 15–19, 2026, The Hague, Netherlands
Chris S. Lin, Joyce Qu, Aditya Rajeev, and Gururaj Saileshwar
95-bits
25-bits
8-bits
Unused / Non-Critical
Page Frame Number
A Flags
Figure 11: 16B PTE Format for 2MB Page Frames. [59]
Approach 1: Exhaust Row-Remapper. After 8 DUEs on a bank, the GPU no longer remaps rows and triggers the remap failure flag on the 9th DUE. Subsequently, any DUEs in the bank persist and become reproducible even after GPU resets and system reboots. Thus, the location of the DUE and the destination of corrupted bit flips in PTEs (i.e., bit flip locations) can be precisely identified. We can trigger this state within 18 hours of hammering on our A6000. Approach 2: Exhaustive Bit-Search. Similar to prior ECC-based exploits [8, 39], we identify the two or three constituent bit flips of a double or triple bit flip, without triggering them together to avoid a DUE that would trigger a row remap. To that end, we use the insight from SoftHammer [13], where they show the attacker can gradually increase hammering intensity to avoid collateral damage. Our bit search runs as follows: first, for each row, we gradually increase intensity (2× → 3× → . . . ) until we observe the first flip in a row. Then, we employ the bit-by-bit search [39] within each 32B segment of the row, masking each of the 256 bits, to find the second or the third flip without triggering the prior flips. This process to locate exploitable double and triple bit errors, without triggering DUEs, takes ∼4 days on our A6000.
8.3
Online Phase: PT Tampering
SDC-based exploit. Using the SDC, the privilege escalation to root on the host is straightforward, as the program does not crash after obtaining the arbitrary Read/Write primitive on the GPU memory. By directly leveraging prior work [50], we achieve hostside privilege escalation with ECC enabled on the GPU, even when the IOMMU is enabled. DUE-based exploit. Using DUEs, once the exploit performs the memory accesses using corrupted PTEs to achieve the arbitrary Read-Write privileges, the GPU kernel terminates within 10 ms. Given this limited time window, this makes directly applying the GPUBreach [50] exploit challenging. On systems where the IOMMU is disabled by default, a common occurrence in Ubuntu [56, 90], we can still achieve host-side privilege escalation within this brief time window, following prior works [30, 90]. Specifically, we modify the pre-placed PTE’s aperture bits (“A” in Figure 11), to map GPU accesses to CPU memory, and use the arbitrary write primitive to overwrite the process’s credential structure (cred), whose address is assumed to be obtained via side channels [10, 50, 51]. By setting euid=0, we get root privileges on the host, similar to prior works [30, 90]; this persists even after the GPU kernel crashes. These steps complete in under 1 ms, within the available time window, practically achieving host-side privilege escalation even with ECC enabled on the GPU, on host systems with IOMMU disabled.
9
Discussion and Limitations
Applicability. GPUThor induces bit flips on all GA10x GDDR6 GPUs we tested (A4000, A4500, A5000, A6000), but not on the HBM, GDDR6X, or newer-generation GDDR6 GPUs we evaluated (see Appendix D). These differences may reflect variations in TRR implementations and the use of Refresh Management (RFM) in some GDDR6X-based chips [58]. Nevertheless, our non-coalescing primitives demonstrate the feasibility of non-uniform, multi-tREFI hammering on NVIDIA GPUs, providing a basis for future works to extend such attacks to newer GPUs.
Prior work [30, 48, 50, 90, 104] shows that GPU physical memory allocation is contiguous and reproducible in single-tenant settings. This allows us to deterministically predict the page frame a PTE will reference after tampering, given the flip locations. Massaging Page Tables. We leverage cuMemMap [30, 50] to duplicate PTEs with identical physical page frame numbers within a PT region. Given the contiguous virtual-to-physical mappings, the corrupted PTE’s destination corresponds to the original virtual address plus the known bit-flip location offset. Prior to hammering, we (1) massage a PT region into the vulnerable row, (2) fill it with duplicated PTEs with cuMemMap, (3) massage a second PT region at the predicted tampered PTE’s destination and fill it using cuMemMap. Obtaining Arbitrary Read/Write. With the PTEs in place, we hammer the profiled bit flips in the target PTE using GPUThor. Then we launch a second GPU kernel that accesses the virtual address obtained from the first cuMemMap, corresponding to the tampered PTE, triggering ECC handling on the flips. If the PTE tampering is successful, we can access the PTEs of the second PT region, and modify them to read/write arbitrary GPU memory or privileged host CPU memory (setting the aperture bits in the PTE [30, 50, 90]).
Newer Reliability Mechanisms in GPUs. Newer NVIDIA GPUs introduce reliability mechanisms [60] with implications for some of our exploits. Server-class Ampere GPUs (A100) and beyond include Error Containment and Dynamic Page Offlining that isolate faults to triggering applications; this avoids full GPU resets or crashes of co-tenant processes, improving resilience to denial-of-service attacks. However, these still rely on SECDED-level ECC meaning that SDCs induced by our triple-bit flips still allow privilege escalation attacks to succeed. RAS Repair, introduced in some Blackwell GPUs, replaces a DRAM channel after repeated row-remapping failures within a bank. While this makes the attack using DUEs more timeconsuming, it does not prevent the attack. Finally, newer GPUs using HBM3/e and GDDR7 DRAM support on-die ECC [36, 37]. While this reduces error visibility, it remains vulnerable to multi-bit flips [57]. Future work can explore exploits on these platforms.
8.4
10
Results
On the ECC-enabled A6000 GPU, we found one SDC and 26 out of 94 DUEs suitable for exploitation (§8.2). For the offline phase, we use Approach-2 (§8.2), which completes in 4 days. The online phase takes under 2 minutes to obtain an arbitrary read/write primitive, with cuMemMap and TLB flushing accounting for most of that time.
Mitigations
Stronger Error Correction. Deploying stronger ECC like Chipkill [14] can improve resilience to multi-bit flips and enhance Rowhammer protections. However, increasing ECC strength may incur nonnegligible storage and bandwidth overheads; existing SECDED ECC in GDDR6 already incurs a 6.25% memory overhead and up to 10%
GPUThor: Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs
slowdown [48, 83]. This motivates future research on stronger and efficient error correction schemes for GPUs. ECC State Monitoring. Just as an attacker can use nvidia-smi reported correctable error counts to identify bit flips (Section 7.1), an administrator can monitor the ECC-related state to detect Rowhammer activity. A spike in row-remapper activity or number of corrected errors can reveal an attack. However, such monitoring also has two limitations that may enable evasion: (1) the row remapper is triggered only by DUEs, not SDCs, and (2) the correctable-error counter becomes unreliable after a few thousand errors and then largely stops incrementing. We leave a detailed investigation of such monitoring mechanisms for future work. Principled Hardware-Level Defenses. Adopting in-DRAM mitigations such as Refresh Management (RFM) and Per-Row Activation Counting (PRAC) [1, 6, 70, 95], or memory-controller-based defenses [69, 72, 76, 78, 85, 96, 97] can be effective mitigations against our attacks. DRAM integrity protections [18, 38, 77] can also detect data corruption via Rowhammer and prevent our exploits.
11
Related Work
Rowhammer Attacks. Rowhammer has been studied extensively on CPU DRAM [41, 63, 66], with attack patterns bypassing inDRAM mitigations in DDR3–5 [11, 21, 33, 34, 57] and on LPDDR [20, 44]. ECCploit [8] and ECC.fail [39] further demonstrate that ECC does not inherently prevent Rowhammer on CPU DRAM. These attacks have enabled privilege escalation [80], cryptographic fault injection [75], RDMA-based attacks [86], browser compromises [11, 12, 23], and attacks on ML models [7, 16, 29, 47, 74, 81, 99]. Recent attacks have explored other sources of data disturbance such as RowPress [53] and ColumnDisturb [102]. GPUHammer [48] first demonstrated Rowhammer attacks on discrete GPUs, followed by attacks on GPU page tables enabling privilege escalation [30, 50, 90]. GPUThor brings non-uniform hammering [33] to GPUs, enabling the first GPU Rowhammer attacks that compromise ECC. GPU Vulnerabilities. Prior work has exposed a broad GPU attack surface spanning data leakage, side channels, memory corruption, and privilege escalation. Residual GPU memory can leak renders and ML outputs [46, 82], while microarchitectural side channels and covert channels leak pixels, model parameters, and other sensitive information [17, 58, 91–93, 103, 104]. CUDA memory-safety bugs enable control-flow hijacking and ML model tampering [25], and CPU-GPU communication channels can leak data in confidentialcomputing settings [24]. GPU Rowhammer [30, 48, 50, 90] has expanded this surface to privilege escalation. GPUThor extends this by demonstrating privilege escalation despite ECC protections. Rowhammer Mitigations. Most defenses target CPU DRAM. Software approaches focus on memory isolation [2, 4, 45, 52, 79, 89], ECC-driven remapping [15, 60], or aggressor rate limiting [5, 19, 100]; these may extend to GPUs with driver support. Hardware-level defenses, such as tracker-based schemes [3, 32, 42, 54, 65, 67, 69, 71– 73, 84, 85, 98, 101], row relocation [76, 78, 94, 97], delayed activations [100], refresh-generating activations [55], page table integrity protection [77], and PRAC-based designs [6, 40, 70, 95], are also applicable to GPU DRAM. However, their latency, bandwidth, and storage overheads on GPUs remain unexplored.
12
CCS ’26, November 15–19, 2026, The Hague, Netherlands
Conclusion
We present GPUThor, the first high-intensity, non-uniform Rowhammer attack on NVIDIA GPUs. By reverse-engineering coalescing on GPUs and TRR on GDDR6 memories, we design multi-tREFI patterns that achieve 500×–23,500× more bit flips than prior GPU attacks. GPUThor also induces multi-bit flips uncorrectable by the SECDED ECC, and enables denial-of-service attacks and the first privilege-escalation attacks on ECC-enabled GPUs. Our results show that the NVIDIA-recommended mitigation of enabling ECC in GPUs is insufficient and stronger defenses are needed.
Acknowledgments We thank Prof. Kaveh Razavi for a conversation that inspired this work. This research was supported by an NSERC Discovery Grant (RGPIN-2023-04796) and an NSERC-CSE Research Communities Grant (ALLRP-588144-23). Any research, opinions, or positions expressed in this work are solely those of the authors and do not represent the official views of NSERC, the Communications Security Establishment Canada, or the Government of Canada.
References [1] Tanj Bennett, Stefan Saroiu, Alec Wolman, and Lucian Cojocar. 2021. Panopticon: A complete in-dram rowhammer mitigation. In Workshop on DRAM Security (DRAMSec), Vol. 22. 110. [2] Carsten Bock, Ferdinand Brasser, David Gens, Christopher Liebchen, and Ahmad-Reza Sadeghi. 2019. RIP-RH: Preventing rowhammer-based interprocess attacks. In Proceedings of the 2019 ACM Asia Conference on Computer and Communications Security. 561–572. [3] F. Nisa Bostanci, ISmail Emir Yüksel, Ataberk Olgun, Konstantinos Kanellopoulos, Yahya Can Tuğrul, A. Giray Yaglıkçı, Mohammad Sadrosadati, and Onur Mutlu. 2024. CoMeT: Count-Min-Sketch-based Row Tracking to Mitigate RowHammer at Low Cost. In 2024 IEEE International Symposium on HighPerformance Computer Architecture (HPCA). 593–612. doi:10.1109/HPCA57 654.2024.00050 [4] Ferdinand Brasser, Lucas Davi, David Gens, Christopher Liebchen, and AhmadReza Sadeghi. 2017. CAn’t touch this: Software-only mitigation against Rowhammer attacks targeting kernel memory. In 26th USENIX Security Symposium (USENIX Security 17). 117–130. [5] Oğuzhan Canpolat, A. Giray Yağlıkçı, Ataberk Olgun, Ismail Emir Yuksel, Yahya Can Tuğrul, Konstantinos Kanellopoulos, Oğuz Ergin, and Onur Mutlu. 2024. BreakHammer: Enhancing RowHammer Mitigations by Carefully Throttling Suspect Threads. In Proceedings of the 2024 57th IEEE/ACM International Symposium on Microarchitecture (Austin, TX, USA) (MICRO ’24). IEEE Press, 915–934. doi:10.1109/MICRO61859.2024.00072 [6] Oğuzhan Canpolat, A Giray Yağlıkçı, Geraldo F Oliveira, Ataberk Olgun, Nisa Bostancı, Ismail Emir Yuksel, Haocong Luo, Oğuz Ergin, and Onur Mutlu. 2025. Chronus: Understanding and Securing the Cutting-Edge Industry Solutions to DRAM Read Disturbance. In 2025 IEEE International Symposium on High Performance Computer Architecture (HPCA). [7] Zachary Coalson, Jeonghyun Woo, Chris S. Lin, Joyce Qu, Yu Sun, Shiyang Chen, Lishan Yang, Gururaj Saileshwar, Prashant Nair, Bo Fang, and Sanghyun Hong. 2025. PrisonBreak: Jailbreaking Large Language Models with at Most Twenty-Five Targeted Bit-flips. arXiv preprint arXiv:2412.07192 (2025). [8] Lucian Cojocar, Kaveh Razavi, Cristiano Giuffrida, and Herbert Bos. 2019. Exploiting Correcting Codes: On the Effectiveness of ECC Memory Against Rowhammer Attacks. In 2019 IEEE Symposium on Security and Privacy (SP). 55–71. doi:10.1109/SP.2019.00089 [9] Shengkun Cui, Archit Patke, Hung Nguyen, Aditya Ranjan, Ziheng Chen, Phuong Cao, Gregory Bauer, Brett Bode, Catello Di Martino, Saurabh Jha, Chandra Narayanaswami, Daby Sow, Zbigniew T. Kalbarczyk, and Ravishankar K. Iyer. 2025. Story of Two GPUs: Characterizing the Resilience of Hopper H100 and Ampere A100 GPUs. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis. Association for Computing Machinery, New York, NY, USA. doi:10.1145/3712285.3759821 [10] Davide Davoli, Martin Avanzini, and Tamara Rezk. 2024. On Kernel’s Safety in the Spectre Era (And KASLR is Formally Dead). In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security. 1091–1105. [11] Finn de Ridder, Pietro Frigo, Emanuele Vannacci, Herbert Bos, Cristiano Giuffrida, and Kaveh Razavi. 2021. SMASH: Synchronized Many-sided Rowhammer
CCS ’26, November 15–19, 2026, The Hague, Netherlands
Attacks from JavaScript. In 30th USENIX Security Symposium (USENIX Security 21). USENIX Association, 1001–1018. https://www.usenix.org/conference/usen ixsecurity21/presentation/ridder [12] Finn de Ridder, Patrick Jattke, and Kaveh Razavi. 2025. Posthammer: pervasive browser-based rowhammer attacks with postponed refresh commands. In Proceedings of the 34th USENIX Conference on Security Symposium (Seattle, WA, USA) (SEC ’25). USENIX Association, USA, Article 291, 18 pages. [13] Finn de Ridder, Patrick Jattke, and Kaveh Razavi. 2025. Softhammer: Exploiting Rowhammer Bit Flips without Crashing. In 5th Workshop on DRAM Security (DRAMSec). [14] Timothy J Dell. 1997. A white paper on the benefits of chipkill-correct ECC for PC server main memory. IBM Microelectronics division 11, 1-23 (1997), 5–7. [15] Andrea Di Dio, Koen Koning, Herbert Bos, and Cristiano Giuffrida. 2023. Copyon-Flip: Hardening ECC Memory Against Rowhammer Attacks. In NDSS ’23. [16] Jianshuo Dong, Han Qiu, Yiming Li, Tianwei Zhang, Yuanjie Li, Zeqi Lai, Chao Zhang, and Shu-Tao Xia. 2023. One-bit flip is all you need: When bit-flip attack meets model training. In Proceedings of the IEEE/CVF International Conference on Computer Vision. 4688–4698. [17] Sankha Baran Dutta, Hoda Naghibijouybari, Arjun Gupta, Nael Abu-Ghazaleh, Andres Marquez, and Kevin Barker. 2023. Spy in the GPU-box: Covert and Side Channel Attacks on Multi-GPU Systems. In Proceedings of the 50th Annual International Symposium on Computer Architecture (Orlando, FL, USA) (ISCA ’23). Association for Computing Machinery, New York, NY, USA, Article 45, 13 pages. doi:10.1145/3579371.3589080 [18] Ali Fakhrzadehgan, Yale N Patt, Prashant J Nair, and Moinuddin K Qureshi. 2022. Safeguard: Reducing the security risk from row-hammer via low-cost integrity protection. In 2022 IEEE International Symposium on High-Performance Computer Architecture (HPCA). IEEE, 373–386. [19] Carina Fiedler, Jonas Juffinger, Sudheendra Raghav Neela, Martin Heckel, Hannes Weissteiner, Abdullah Giray Yağlıkçı, Florian Adamsky, and Daniel Gruss. 2026. Memory Band-Aid: A Principled Rowhammer Defense-in-Depth. In Network and Distributed System Security (NDSS) 2026. [20] Pietro Frigo, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi. 2018. Grand pwning unit: Accelerating microarchitectural attacks with the GPU. In 2018 ieee symposium on security and privacy (sp). IEEE, 195–210. [21] Pietro Frigo, Emanuele Vannacci, Hasan Hassan, Victor van der Veen, Onur Mutlu, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi. 2020. TRRespass: Exploiting the Many Sides of Target Row Refresh. In 2020 IEEE Symposium on Security and Privacy (SP). 747–762. doi:10.1109/SP40000.2020.00090 [22] Google. 2025. Share GPUs across workloads with GPU time-sharing. https: //cloud.google.com/kubernetes- engine/docs/how- to/timesharing- gpus. Accessed: 2025-01-22. [23] Daniel Gruss, Clémentine Maurice, and Stefan Mangard. 2016. Rowhammer. js: A remote software-induced fault attack in javascript. In Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA). Springer, 300–321. [24] Zhongshu Gu, Enriquillo Valdez, Salman Ahmed, Julian James Stephen, Michael Le, Hani Jamjoom, Shixuan Zhao, and Zhiqiang Lin. 2025. NVIDIA GPU confidential computing demystified. arXiv preprint arXiv:2507.02770 (2025). [25] Yanan Guo, Zhenkai Zhang, and Jun Yang. 2024. GPU Memory Exploitation for Fun and Profit. In 33rd USENIX Security Symposium (USENIX Security 24). USENIX Association, Philadelphia, PA, 4033–4050. https://www.usenix.org/c onference/usenixsecurity24/presentation/guo-yanan [26] R. W. Hamming. 1950. Error detecting and error correcting codes. The Bell System Technical Journal 29, 2 (1950), 147–160. doi:10.1002/j.1538-7305.1950.tb00463.x [27] Hasan Hassan, Yahya Can Tugrul, Jeremie S. Kim, Victor van der Veen, Kaveh Razavi, and Onur Mutlu. 2021. Uncovering In-DRAM RowHammer Protection Mechanisms: A New Methodology, Custom RowHammer Patterns, and Implications. In 54th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO). Association for Computing Machinery, New York, NY, USA, 1198–1213. doi:10.1145/3466752.3480110 [28] Martin Heckel, Nima Sayadi, Jonas Juffinger, Carina Fiedler, Daniel Gruss, and Florian Adamsky. 2026. FLIPPYRAM: A Large-Scale Study of Rowhammer Prevalence. In Network and Distributed System Security (NDSS) 2026. [29] Sanghyun Hong, Pietro Frigo, Yigitcan Kaya, Cristiano Giuffrida, and Tudor Dumitras. 2019. Terminal Brain Damage: Exposing the Graceless Degradation in Deep Neural Networks Under Hardware Fault Attacks. In 28th USENIX Security Symposium (USENIX Security 19). USENIX Association, Santa Clara, CA, 497–514. https://www.usenix.org/conference/usenixsecurity19/presentation/hong [30] Yichang Hu, Noah Brown, Yuhang Chen, Joshua Bakita, Tianlong Chen, Daniel Genkin, and Andrew Kwong. 2026. GDDRHammer: Greatly Disturbing DRAM Rows — Cross-Component Rowhammer Attacks from Modern GPUs. In Proceedings of the 2026 IEEE Symposium on Security and Privacy (SP). [31] Ilya-Zlobintsev. 2026. GitHub - ilya-zlobintsev/LACT: Linux GPU Configuration And Monitoring Tool. https://github.com/ilya-zlobintsev/LACT [32] Aamer Jaleel, Gururaj Saileshwar, Stephen W. Keckler, and Moinuddin Qureshi. 2024. PrIDE: Achieving Secure Rowhammer Mitigation with Low-Cost InDRAM Trackers. In 2024 ACM/IEEE 51st Annual International Symposium on Computer Architecture (ISCA). 1157–1172. doi:10.1109/ISCA59077.2024.00087
Chris S. Lin, Joyce Qu, Aditya Rajeev, and Gururaj Saileshwar
[33] Patrick Jattke, Victor Van Der Veen, Pietro Frigo, Stijn Gunter, and Kaveh Razavi. 2022. BLACKSMITH: Scalable Rowhammering in the Frequency Domain. In 2022 IEEE Symposium on Security and Privacy (SP). 716–734. doi:10.1109/SP4621 4.2022.9833772 [34] Patrick Jattke, Max Wipfli, Flavien Solt, Michele Marazzi, Matej Bölcskei, and Kaveh Razavi. 2024. ZenHammer: Rowhammer Attacks on AMD Zen-based Platforms. In 33rd USENIX Security Symposium (USENIX Security 24). USENIX Association, Philadelphia, PA, 1615–1633. https://www.usenix.org/conference/ usenixsecurity24/presentation/jattke [35] JEDEC. 2023. GDDR6 Specification (JESD250D). (2023). [36] JEDEC. 2023. HBM3 Specification (JESD238A). (2023). [37] JEDEC. 2026. GDDR7 Specification (JESD239D). (2026). [38] Jonas Juffinger, Lukas Lamster, Andreas Kogler, Maria Eichlseder, Moritz Lipp, and Daniel Gruss. 2023. CSI: Rowhammer–Cryptographic security and integrity against rowhammer. In 2023 IEEE Symposium on Security and Privacy (SP). IEEE, 1702–1718. [39] Nureddin Kamadan, Walter Wang, Stephan van Schaik, Christina Garman, Daniel Genkin, and Yuval Yarom. 2025. ECC. fail: Mounting Rowhammer Attacks on DDR4 Servers with ECC Memory. In 34th USENIX Security Symposium (USENIX Security 25). 5679–5698. [40] Jumin Kim, Seungmin Baek, Hwayong Nam, Minbok Wi, Nam Sung Kim, and Jung Ho Ahn. 2026. PVAC: A RowHammer Mitigation Architecture Exploiting Per-victim-row Counting. arXiv:2604.20576 [cs.CR] https://arxiv.org/abs/2604 .20576 [41] Jeremie S. Kim, Minesh Patel, A. Giray Yağlıkçı, Hasan Hassan, Roknoddin Azizi, Lois Orosa, and Onur Mutlu. 2020. Revisiting RowHammer: An Experimental Analysis of Modern DRAM Devices and Mitigation Techniques. In 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA). 638–651. doi:10.1109/ISCA45697.2020.00059 [42] M. Kim, J. Park, Y. Park, W. Doh, N. Kim, T. Ham, J. W. Lee, and J. Ahn. 2022. Mithril: Cooperative Row Hammer Protection on Commodity DRAM Leveraging Managed Refresh. In 2022 IEEE International Symposium on High-Performance Computer Architecture (HPCA). [43] Yoongu Kim, Ross Daly, Jeremie Kim, Chris Fallin, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai, and Onur Mutlu. 2014. Flipping bits in memory without accessing them: an experimental study of DRAM disturbance errors. In Proceedings of the 41st Annual International Symposium on Computer Architecture (ISCA). 361–372. [44] Andreas Kogler, Jonas Juffinger, Salman Qazi, Yoongu Kim, Moritz Lipp, Nicolas Boichat, Eric Shiu, Mattias Nissler, and Daniel Gruss. 2022. Half-Double: Hammering From the Next Row Over. In 31st USENIX Security Symposium (USENIX Security 22). USENIX Association, Boston, MA, 3807–3824. https://www.usen ix.org/conference/usenixsecurity22/presentation/kogler-half-double [45] Radhesh Krishnan Konoth, Marco Oliverio, Andrei Tatar, Dennis Andriesse, Herbert Bos, Cristiano Giuffrida, and Kaveh Razavi. 2018. ZebRAM: comprehensive and compatible software protection against rowhammer attacks. In OSDI 18. [46] Sangho Lee, Youngsok Kim, Jangwoo Kim, and Jong Kim. 2014. Stealing Webpages Rendered on Your Browser by Exploiting GPU Vulnerabilities. In 2014 IEEE Symposium on Security and Privacy. 19–33. doi:10.1109/SP.2014.9 [47] Xiang Li, Ying Meng, Junming Chen, Lannan Luo, and Qiang Zeng. 2025. Rowhammer-Based Trojan Injection: One Bit Flip Is Sufficient for Backdooring DNNs. In 34th USENIX Security Symposium (USENIX Security 25). 6319–6337. [48] Chris S. Lin, Joyce Qu, and Gururaj Saileshwar. 2025. GPUHammer: Rowhammer Attacks on GPU Memories are Practical. In 34th USENIX Security Symposium (USENIX Security 25). 5719–5738. [49] Chris S. Lin, Yuqin Yan, Guozhen Ding, Joyce Qu, Joseph Zhu, David Lie, and Gururaj Saileshwar. 2026. GPUBreach Code Repository. https://github.com/sithlab/gpubreach. Accessed: 2026-04-27. [50] Chris S. Lin, Yuqin Yan, Guozhen Ding, Joyce Qu, Joseph Zhu, David Lie, and Gururaj Saileshwar. 2026. GPUBreach: Privilege Escalation Attacks on GPUs using Rowhammer. In Proceedings of the 2026 IEEE Symposium on Security and Privacy (SP). [51] William Liu, Joseph Ravichandran, and Mengjia Yan. 2023. Entrybleed: A universal kaslr bypass against kpti on linux. In Proceedings of the 12th International Workshop on Hardware and Architectural Support for Security and Privacy. 10–18. [52] Kevin Loughlin, Jonah Rosenblum, Stefan Saroiu, Alec Wolman, Dimitrios Skarlatos, and Baris Kasikci. 2023. Siloz: Leveraging DRAM Isolation Domains to Prevent Inter-VM Rowhammer. In 29th Symposium on Operating Systems Principles (SOSP). [53] Haocong Luo, Ataberk Olgun, Abdullah Giray Yağlıkçı, Yahya Can Tuğrul, Steve Rhyner, Meryem Banu Cavlak, Joël Lindegger, Mohammad Sadrosadati, and Onur Mutlu. 2023. Rowpress: Amplifying read disturbance in modern dram chips. In 50th International Symposium on Computer Architecture (ISCA). [54] Michele Marazzi, Patrick Jattke, Flavien Solt, and Kaveh Razavi. 2022. Protrr: Principled yet optimal in-dram target row refresh. In IEEE Symposium on Security and Privacy (SP). 735–753.
GPUThor: Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs
[55] Michele Marazzi, Flavien Solt, Patrick Jattke, Kubo Takashi, and Kaveh Razavi. 2023. REGA: Scalable Rowhammer Mitigation with Refresh-Generating Activations. In IEEE Symposium on Security and Privacy (SP). [56] A Theodore Markettos, Colin Rothwell, Brett F Gutstein, Allison Pearce, Peter G Neumann, Simon W Moore, and Robert NM Watson. 2019. Thunderclap: Exploring vulnerabilities in operating system IOMMU protection via DMA from untrustworthy peripherals. In Proceedings of Network and Distributed Systems Security (NDSS) Symposium. [57] Diego Meyer, Patrick Jattke, Michele Marazzi, Salman Qazi, Daniel Moghimi, and Kaveh Razavi. 2026. Phoenix: Rowhammer Attacks on DDR5 with SelfCorrecting Synchronization. In S&P (Oakland). [58] Ravan Nazaraliyev, Yicheng Zhang, Sankha Baran Dutta, Andres Marquez, Kevin Barker, and Nael Abu-Ghazaleh. 2025. Not so refreshing: attacking GPUs using RFM rowhammer mitigation. In Proceedings of the 34th USENIX Conference on Security Symposium (SEC). [59] NVIDIA. 2019. Pascal MMU Format. https://github.com/NVIDIA/open-gpudoc/blob/master/pascal/gp100-mmu-format.pdf. [60] NVIDIA. 2025. NVIDIA GPU Memory Error Management. https://docs.nvidia. com/deploy/a100-gpu-mem-error-mgmt/overview.html Accessed: 2026-04-21. [61] NVIDIA. 2025. Security Notice: Rowhammer – July 2025. https://nvidia.custhel p.com/app/answers/detail/a_id/5671. [62] NVIDIA. 2026. CUDA C++ Best Practices Guide. https://docs.nvidia.com/cuda /cuda-c-best-practices-guide/index.html Accessed: 2026-04-21. [63] Ataberk Olgun, F. Nisa Bostanci, Ismail Emir Yuksel, Oguzhan Canpolat, Haocong Luo, Geraldo F. Oliveira, A. Giray Yaglikci, Minesh Patel, and Onur Mutlu. 2025. Variable Read Disturbance: An Experimental Analysis of Temporal Variation in DRAM Read Disturbance. In IEEE International Symposium on High Performance Computer Architecture (HPCA). [64] Ataberk Olgun, Majd Osseiran, A Giray Yağlıkçı, Yahya Can Tuğrul, Haocong Luo, Steve Rhyner, Behzad Salami, Juan Gomez Luna, and Onur Mutlu. 2023. An experimental analysis of RowHammer in HBM2 DRAM chips. In 2023 53rd Annual IEEE/IFIP International Conference on Dependable Systems and NetworksSupplemental Volume (DSN-S). IEEE, 151–156. [65] Ataberk Olgun, Yahya Can Tugrul, Nisa Bostanci, Ismail Emir Yuksel, Haocong Luo, Steve Rhyner, Abdullah Giray Yaglikci, Geraldo F. Oliveira, and Onur Mutlu. 2024. ABACuS: all-bank activation counters for scalable and low overhead RowHammer mitigation. In Proceedings of the 33rd USENIX Conference on Security Symposium (Philadelphia, PA, USA) (SEC ’24). USENIX Association, USA, Article 89, 18 pages. [66] Lois Orosa, Abdullah Giray Yaglikci, Haocong Luo, Ataberk Olgun, Jisung Park, Hasan Hassan, Minesh Patel, Jeremie S. Kim, and Onur Mutlu. 2021. A Deeper Look into RowHammer’s Sensitivities: Experimental Analysis of Real DRAM Chips and Implications on Future Attacks and Defenses. In MICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO ’21). ACM, 1182–1197. doi:10.1145/3466752.3480069 [67] Yeonhong Park, Woosuk Kwon, Eojin Lee, Tae Jun Ham, Jung Ho Ahn, and Jae W Lee. 2020. Graphene: Strong yet Lightweight Row Hammer Protection. In 2020 53rd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, 1–13. [68] Peter Pessl, Daniel Gruss, Clémentine Maurice, Michael Schwarz, and Stefan Mangard. 2016. DRAMA: Exploiting DRAM Addressing for Cross-CPU Attacks. In 25th USENIX Security Symposium (USENIX Security 16). USENIX Association, Austin, TX, 565–581. https://www.usenix.org/conference/usenixsecurity16/tec hnical-sessions/presentation/pessl [69] Moinuddin Qureshi. 2025. AutoRFM: Scaling Low-Cost in-DRAM Trackers to Ultra-Low Rowhammer Thresholds . In 2025 IEEE International Symposium on High Performance Computer Architecture (HPCA). 991–1004. doi:10.1109/HPCA 61900.2025.00078 [70] Moinuddin Qureshi and Salman Qazi. 2025. Moat: Securely mitigating rowhammer with per-row activation counters. In Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1. 698–714. [71] Moinuddin Qureshi, Salman Qazi, and Aamer Jaleel. 2024. MINT: Securely Mitigating Rowhammer with a Minimalist in-DRAM Tracker . In 2024 57th IEEE/ACM International Symposium on Microarchitecture (MICRO). 899–914. doi:10.1109/MICRO61859.2024.00071 [72] Moinuddin Qureshi, Aditya Rohan, Gururaj Saileshwar, and Prashant J. Nair. 2022. Hydra: enabling low-overhead mitigation of row-hammer at ultra-low thresholds via hybrid tracking. In Proceedings of the 49th Annual International Symposium on Computer Architecture (ISCA). doi:10.1145/3470496.3527421 [73] Moinuddin K. Qureshi. 2026. SALT: Track-and-Mitigate Subarrays, Not Rows, for Blast-Radius-Free Rowhammer Defense. In 2026 IEEE International Symposium on High Performance Computer Architecture (HPCA). 1–16. doi:10.1109/HPCA68 181.2026.11408602 [74] Adnan Siraj Rakin, Zhezhi He, and Deliang Fan. 2019. Bit-flip attack: Crushing neural network with progressive bit search. In Proceedings of the IEEE/CVF International Conference on Computer Vision. 1211–1220.
CCS ’26, November 15–19, 2026, The Hague, Netherlands
[75] Kaveh Razavi, Ben Gras, Erik Bosman, Bart Preneel, Cristiano Giuffrida, and Herbert Bos. 2016. Flip Feng Shui: Hammering a Needle in the Software Stack. In 25th USENIX Security Symposium (USENIX Security). https://www.usenix.o rg/conference/usenixsecurity16/technical-sessions/presentation/razavi [76] Gururaj Saileshwar, Bolin Wang, Moinuddin Qureshi, and Prashant J. Nair. 2022. Randomized row-swap: mitigating Row Hammer by breaking spatial correlation between aggressor and victim rows. In 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS). [77] Anish Saxena, Gururaj Saileshwar, Jonas Juffinger, Andreas Kogler, Daniel Gruss, and Moinuddin Qureshi. 2023. PT-Guard: Integrity-Protected Page Tables to Defend Against Breakthrough Rowhammer Attacks. In 2023 53rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). 95–108. doi:10.1109/DSN58367.2023.00022 [78] Anish Saxena, Gururaj Saileshwar, Prashant J. Nair, and Moinuddin Qureshi. 2022. AQUA: Scalable Rowhammer Mitigation by Quarantining Aggressor Rows at Runtime. In 2022 55th IEEE/ACM International Symposium on Microarchitecture (MICRO). 108–123. doi:10.1109/MICRO56248.2022.00022 [79] Anish Saxena, Walter Wang, and Alexandros Daglis. 2025. Citadel: Rethinking Memory Allocation to Safeguard Against Inter-Domain Rowhammer Exploits. In Proceedings of the 58th IEEE/ACM International Symposium on Microarchitecture (MICRO). 1117–1131. [80] Mark Seaborn and Thomas Dullien. 2015. Exploiting the DRAM rowhammer bug to gain kernel privileges. Google Project Zero. https://googleprojectzero.bl ogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html Accessed: 2025-11-05. [81] Mrityunjay Shukla, Shubham Roy, Sayandeep Saha, and Biswabandan Panda. 2026. PRowhammer: Propagating Bit-flips from CPU to GPU. (2026). [82] Tyler Sorensen and Heidy Khlaaf. 2024. LeftoverLocals: Listening to LLM Responses Through Leaked GPU Local Memory. In arXiv preprint arXiv:2401.16603. https://arxiv.org/abs/2401.16603 [83] Michael B Sullivan, Mohamed Tarek Ibn Ziad, Aamer Jaleel, and Stephen W Keckler. 2023. Implicit memory tagging: No-overhead memory safety using alias-free tagged ecc. In 50th Annual International Symposium on Computer Architecture (ISCA). [84] Hritvik Taneja, Ali Hajiabadi, Michele Marazzi, Kaveh Razavi, and Moinuddin Qureshi. 2026. MIRZA: Efficiently Mitigating Rowhammer with Randomization and ALERT. In 2026 IEEE International Symposium on High Performance Computer Architecture (HPCA). 1–13. doi:10.1109/HPCA68181.2026.11408571 [85] Hritvik Taneja and Moin Qureshi. 2025. DREAM: Enabling Low-Overhead Rowhammer Mitigation via Directed Refresh Management. In Proceedings of the 52nd Annual International Symposium on Computer Architecture (ISCA ’25). Association for Computing Machinery, New York, NY, USA, 776–792. doi:10.1 145/3695053.3731117 [86] Andrei Tatar, Radhesh Krishnan Konoth, Elias Athanasopoulos, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi. 2018. Throwhammer: Rowhammer Attacks over the Network and Defenses. In 2018 USENIX Annual Technical Conference (USENIX ATC). https://www.usenix.org/conference/atc18/presentation/tatar [87] TechPowerUp. 2025. NVIDIA NVFlash. https://www.techpowerup.com/down load/nvidia-nvflash/ Accessed: 2026-04-21. [88] Victor van der Veen, Yanick Fratantonio, Martina Lindorfer, Daniel Gruss, Clementine Maurice, Giovanni Vigna, Herbert Bos, Kaveh Razavi, and Cristiano Giuffrida. 2016. Drammer: Deterministic Rowhammer Attacks on Mobile Platforms. In 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS). https://doi.org/10.1145/2976749.2978406 [89] Victor Van der Veen, Martina Lindorfer, Yanick Fratantonio, Harikrishnan Padmanabha Pillai, Giovanni Vigna, Christopher Kruegel, Herbert Bos, and Kaveh Razavi. 2018. GuardION: Practical mitigation of DMA-based rowhammer attacks on ARM. In International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Springer, 92–113. [90] Junpeng Wan, Yanan Guo, Zhi Zhang, Zhuo Li, Dave (Jing) Tian, and Zhenkai Zhang. 2026. GeForge: Hammering GDDR Memory to Forge GPU Page Tables for Fun and Profit. In Proceedings of the 2026 IEEE Symposium on Security and Privacy (SP). [91] Alan Wang, Pranav Gopalkrishnan, Yingchen Wang, Christopher W. Fletcher, Hovav Shacham, David Kohlbrenner, and Riccardo Paccagnella. 2025. Pixnapping: Bringing Pixel Stealing out of the Stone Age. In Proceedings of the ACM Conference on Computer and Communications Security (CCS). [92] Yingchen Wang, Riccardo Paccagnella, Zhao Gang, Willy R. Vasquez, David Kohlbrenner, Hovav Shacham, and Christopher W. Fletcher. 2024. GPU.zip: On the Side-Channel Implications of Hardware-Based Graphical Data Compression. In 2024 IEEE Symposium on Security and Privacy (SP). 3716–3734. doi:10.1109/SP 54263.2024.00084 [93] Junyi Wei, Yicheng Zhang, Zhe Zhou, Zhou Li, and Mohammad Abdullah Al Faruque. 2020. Leaky DNN: Stealing Deep-Learning Model Secret with GPU Context-Switching Side-Channel. In 2020 50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). 125–137. doi:10.1109/ DSN48063.2020.00031
CCS ’26, November 15–19, 2026, The Hague, Netherlands
A
Open Science
Our artifact contains the code for our key results, including the Rowhammer attack campaigns (Table 3), the reverse engineering (Table 2 and Figures 4, 6, 7), and the campaigns with ECC (Section 7). Our code will be available at https://github.com/sith-lab/gputhor.
B
Ethical Considerations
We responsibly disclosed our findings to NVIDIA and the major cloud providers (Google, Microsoft, AWS) prior to the public disclosure. We also notified the cloud GPU provider whose GPUs we found had ECC disabled. All experiments were conducted on locally owned GPUs or on cloud GPUs within VMs we controlled, without any impact to other users. All ECC-enabled experiments (DoS and privilege escalation) were performed only on locally owned GPUs.
C
Generative AI Usage
We used GPT-5.2 and Claude Sonnet 4.6 and Opus 5 for minor grammatical corrections and light stylistic refinements of the manuscript. All such edits were carefully reviewed and verified by the authors.
D
Evaluation on Other GPUs
We tested several other GPUs available through cloud providers. For each GPU in Table 6, we generate a Row Set for 1GB of memory and perform GPUThor across all intensity levels (2× to 6.6×). However, other than the A4000-A6000 with GDDR6 memory, none have bit flips with our attack patterns, suggesting different TRR implementations that may require more sophisticated hammering or lack of a vulnerability to Rowhammer. Table 6: Evaluations on Other GPUs GDDR6
Flips
E
GDDR6X
HBM2
3080 Mobile (GA104)
A10 (GA102)
A2000-6000 ADA (AD102-107)
L4 (AD104)
L40 (AD102)
4090 (AD102)
A30 (GA100)
No
No
No
No
No
No
No
Data Pattern Dependency
Figure 12 shows the effect of aggressor and victim data patterns on the number of bit flips in GPUThor campaigns, previously discussed in Table 3. Consistent with prior work [30, 48], we see that victim/attacker data patterns of 0xff/00 induces the most bit flips, triggering more than half the flips observed in our campaigns.
00 00
/ff
aa /55 aa /55
0
/aa 55
Data Pattern (Victim/Aggressor)
/ff
/aa 55
0 ff/0
00
/ff
100% A6000 75% 50% 25% 0%
aa /55
/aa 55
0
100% A5000 75% 50% 25% 0%
ff/0
00
/ff
100% A4500 75% 50% 25% 0%
aa /55
/aa 55
ff/0
0
100% A4000 75% 50% 25% 0%
ff/0
Fraction of all observed flips
[94] Minbok Wi, Jaehyun Park, Seoyoung Ko, Michael Jaemin Kim, Nam Sung Kim, Eojin Lee, and Jung Ho Ahn. 2023. SHADOW: Preventing Row Hammer in DRAM with Intra-Subarray Row Shuffling. In HPCA. [95] Jeonghyun Woo, Shaopeng Chris Lin, Prashant J Nair, Aamer Jaleel, and Gururaj Saileshwar. 2025. Qprac: Towards secure and practical prac-based rowhammer mitigation using priority queues. In 2025 IEEE International Symposium on High Performance Computer Architecture (HPCA). [96] Jeonghyun Woo and Prashant J. Nair. 2025. DAPPER: A Performance-AttackResilient Tracker for RowHammer Defense. In 2025 IEEE International Symposium on High Performance Computer Architecture (HPCA). 1005–1020. doi:10.110 9/HPCA61900.2025.00079 [97] Jeonghyun Woo, Gururaj Saileshwar, and Prashant J Nair. 2023. Scalable and Secure Row-Swap: Efficient and Safe Row Hammer Mitigation in Memory Systems. In HPCA. [98] Runjin Wu, Meng Zhang, You Zhou, Changsheng Xie, and Fei Wu. 2026. APT: Securing Against DRAM Read Disturbance via Adaptive Probabilistic In-DRAM Trackers. In Proceedings of the 31st ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2 (USA) (ASPLOS ’26). Association for Computing Machinery, New York, NY, USA, 137–156. doi:10.1145/3779212.3790126 [99] Fan Yao, Adnan Siraj Rakin, and Deliang Fan. 2020. DeepHammer: Depleting the Intelligence of Deep Neural Networks through Targeted Chain of Bit Flips. In USENIX Security. https://www.usenix.org/conference/usenixsecurity20/pre sentation/yao [100] A. Giray Yağlikçi, Minesh Patel, Jeremie S. Kim, Roknoddin Azizi, Ataberk Olgun, Lois Orosa, Hasan Hassan, Jisung Park, Konstantinos Kanellopoulos, Taha Shahroodi, Saugata Ghose, and Onur Mutlu. 2021. BlockHammer: Preventing RowHammer at Low Cost by Blacklisting Rapidly-Accessed DRAM Rows. In HPCA. [101] Abdullah Giray Yağlıkçı, Yahya Can Tuğrul, Geraldo F. Oliveira, İsmail Emir Yüksel, Ataberk Olgun, Haocong Luo, and Onur Mutlu. 2024. Spatial VariationAware Read Disturbance Defenses: Experimental Analysis of Real DRAM Chips and Implications on Future Solutions. In 2024 IEEE International Symposium on High-Performance Computer Architecture (HPCA). 560–577. doi:10.1109/HPCA 57654.2024.00048 [102] Ismail Emir Yuksel, Ataberk Olgun, Nisa Bostanci, Haocong Luo, Abdullah Giray Yaglikci, and Onur Mutlu. 2025. ColumnDisturb: Understanding Column-based Read Disturbance in Real DRAM Chips and Implications for Future Systems. In Proceedings of the 58th IEEE/ACM International Symposium on Microarchitecture (MICRO). 975–994. [103] Yicheng Zhang, Ravan Nazaraliyev, Sankha Baran Dutta, Andres Marquez, Kevin Barker, and Nael Abu-Ghazaleh. 2025. NVBleed: Covert and Side-Channel Attacks on NVIDIA Multi-GPU Interconnect. arXiv preprint arXiv:2503.17847 (2025). [104] Zhenkai Zhang, Tyler Allen, Fan Yao, Xing Gao, and Rong Ge. 2023. TunneLs for Bootlegging: Fully Reverse-Engineering GPU TLBs for Challenging Isolation Guarantees of NVIDIA MIG. In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (Copenhagen, Denmark) (CCS ’23). 15 pages. doi:10.1145/3576915.3616672
Chris S. Lin, Joyce Qu, Aditya Rajeev, and Gururaj Saileshwar
Figure 12: Percentage of Unique Flips Found per Data Pattern for each GPU. We revisit the aggressor–victim distance distribution reported in prior work [30, 48], measured separately for each data pattern. Figure 13 shows that each data pattern yields a distinct distance distribution for bit flips. Most victim/aggressor data patterns trigger bit flips in victim rows that are logically at most 15 rows away from aggressor rows, validating that there is a non-linear mapping of logical rows to physical rows in the GDDR6 DRAM, as previously observed by GDDRHammer [30]. However, the victim/aggressor data pattern 0xAA/55 has bit flips only when an aggressor row is within a logical distance of 3. This suggests that certain physical rows (where the logical distances between aggressor and victim are larger than 3) are not vulnerable to this data pattern, as they are to other data patterns. We hypothesize that this could be due to differences in data scramblers used in different parts of the bank. This data dependence in the Rowhammer susceptibility, linked to spatial locations in the bank, could lead to new side-channels that leak the data in neighboring rows. We leave explorations of this for future work.
15
14
13
|Aggressor Row Victim Row|
Figure 13: Aggressor-to-Victim Distance distribution for different Data Patterns. Data collected from bit flips occurring across all campaigns and GPUs.
F
Unique Decoys Sensitivity Analysis
In Section 5, our attack patterns utilize unique, randomly selected decoy rows (one activation per decoy). However, for counter-based TRR designs [21], issuing more than one ACT per decoy row may evict aggressors more reliably from the TRR sampler. To evaluate this, we study whether the frequency of decoy activations influences attack effectiveness. For a given aggressor activation count in a 18 tREFI hammering pattern, we progressively reduce the number
CCS ’26, November 15–19, 2026, The Hague, Netherlands
of unique decoy rows in the pattern (keeping the total decoy activations constant) until bit flips are no longer observed. Contrary to our hypothesis, Figure 14 shows that at higher aggressor activation counts, successful attacks require more unique decoys rather than repeated accesses to the same rows. Moreover, this threshold grows exponentially with increasing hammering intensity. Thus, unique decoys are preferred to fool the TRR in GDDR6 compared to repeated activations to the same decoy. This suggests that the TRR tracker in Samsung GDDR6 memories is likely counter-less or has a very small saturating counter per entry.
Min. Unique Decoys to See Bit Flip
15
14
7 13
6
5
3
2
mean = 6.5
7
3
2
1
|Aggressor Row Victim Row|
Pattern: 0x55AA
13500 12000 10500 9000 7500 6000 4500 3000 1500 0
6
Count
mean = 2.0
|Aggressor Row Victim Row|
5
Pattern: 0xAA55
mean = 4.3
3
1
|Aggressor Row Victim Row|
Pattern: 0xFF00
13500 12000 10500 9000 7500 6000 4500 3000 1500 0
1
15
14
7 13
6
5
3
Count
mean = 4.0
2
Pattern: 0x00FF
2
40000 35000 30000 25000 20000 15000 10000 5000 0
1
Count
40000 35000 30000 25000 20000 15000 10000 5000 0
Count
GPUThor: Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs
28 27 26 25 24
16
20
40 60 80 100 120 Aggressor Activation Count (N per 18 TREFI)
140
Figure 14: Minimum unique decoy rows required to trigger bit flip for the 18-TREFI pattern when we extend our hammering to higher intensity. At 56 ACTs or less, only 16 unique decoys (the tracker size) are needed, but when the aggressor activation counts are increased to 135 ACTs, up to 400 unique decoy rows are required to trigger bit flips.