Home / Ciberseguridad / Rowhammer: hammering one memory row until the data next door flips on its own

Rowhammer: hammering one memory row until the data next door flips on its own

An attacker does not need to write to your memory to change what is inside it. Reading it hard, fast and always in the same place is enough. That is the whole idea behind Rowhammer, a physical defect in DRAM that has spent a decade moving from laboratory curiosity to a measured problem across thousands of real machines, and that in 2025 jumped to the memory chips inside graphics cards.

A memory cell is a tiny bucket that leaks

Every DRAM bit lives in a cell made of one transistor and one capacitor (the 1T1C architecture). The capacitor holds on the order of femtofarads: a minute capacitance that stores charge to mean a 1 and no charge to mean a 0. Because that charge drains away on its own within milliseconds, the chip refreshes itself constantly: in DDR5 the interval between refreshes (tREFI) is about 3.9 microseconds and the full refresh window (tREFW) is around 32 milliseconds. Above 85 degrees Celsius the controller doubles the rate so it does not lose data.

To read or write a value, the controller activates a wordline (ACT) and the whole row dumps onto the bitlines, where a sense amplifier decides whether each cell held a 0 or a 1. Reading destroys the content, so every activation ends by writing the row back. That detail is the crack the attack walks through.

Hammer one row and its neighbour gets it wrong

Activating the same row tens of thousands of times inside a single refresh window creates electrical coupling with the neighbouring rows: their capacitors lose charge faster than expected and some bits flip on their own. This is called read disturbance, and it is neither a software bug nor a manufacturing defect: it is the expected behaviour of a capacitor pushed to its limit.

Known patterns have kept getting sharper. The classic double-sided attack hammers the two rows that surround the victim. Half-Double, described in 2021, showed that the effect reaches rows two positions away, because the coupling does not stop at the immediate neighbour. And RowPress, presented in late 2023, changes the strategy: instead of opening and closing rows at full speed, it leaves them open for long stretches, with far fewer activations per second, under the detection thresholds.

Three defences and their cracks

The first line is Target Row Refresh (TRR): the memory itself keeps an activation counter per row and, when it senses hammering, refreshes the neighbouring rows on its own. The second is module-level ECC, standard on servers: a SECDED scheme corrects one bit and detects two. The third is on-die ECC (ODECC), which shipped as standard with DDR5; it should not be confused with module ECC, because it corrects errors in the die’s own manufacturing but never tells the operating system that a flip happened.

There lies the paradox: the attacker needs exactly one bit, and one bit is precisely what ECC silently corrects. A flip in a page table entry should not crash the machine, it should stay invisible just long enough to grant privileges. And TRR has a structural problem: the circuit that decides which activations look suspicious is opaque, half-documented, and has to be attacked without being able to see it.

Phoenix: how TRR was broken on DDR5

The COMSEC group at ETH Zurich, working with Google, took that black box apart with FPGA experiments and a clever side channel: they used the memory’s own retention errors to deduce which rows TRR had refreshed by itself. That revealed the sampling was not uniform; it repeats every 128 refresh intervals (eight times what earlier patterns assumed) and, inside each cycle, some intervals are almost never watched. The resulting attack, named Phoenix, fires very long patterns that hammer only inside those gaps and that resynchronise themselves whenever the scheduler misses a refresh. The result: bit flips on 15 out of 15 SK Hynix DDR5 modules, and the first privilege escalation on a production DDR5 PC, in as little as 109 seconds, by corrupting a page table entry. It is tracked as CVE-2025-6202, was presented at IEEE S&P 2026 and forced a BIOS advisory for AMD client machines.

The mitigation the authors themselves verified is uncomfortable: tripling the refresh rate (tREFI down to 1.3 microseconds) stops Phoenix, but costs roughly 8.4 percent of performance on the SPEC CPU2017 workload. In other words, you buy security with bandwidth.

From the lab to the fleet

JEDEC has already folded a named mechanism into the DDR5 standard, PRAC (per-row activation counting), which tracks every row instead of sampling. It sounds final until you look closely: if no row is activated more than a few hundred times per refresh window, the counter never trips. The margin between what it takes to flip a bit and what it takes to raise the alarm is the new battleground.

And one expectation needs correcting. The FlippyR.AM study, presented at NDSS 2026 by researchers from Hof and Graz, analysed 1,006 data sets from 822 real systems and concluded that fully automated attacks, the kind anyone can launch without a lab FPGA, work on a noticeably smaller share of machines than bench experiments suggested. The flaw has not evaporated: the distance between a demonstration and a weapon is simply bigger than it looks, and it depends on the attacker’s patience, how much control they have over the machine and how long they can keep the pattern running unnoticed.

Now GPUs too, with AI in the middle

The most significant leap is graphics memory. The University of Toronto team demonstrated with GPUHammer, published at USENIX Security 2025, the first Rowhammer on the GDDR6 of a discrete GPU: on an RTX A6000 they triggered eight flips, one per hammered bank, and showed that a single bit placed wrongly in the most significant bit of the exponent of an FP16 weight can drop a classification model’s accuracy from 80 percent to below 0.5 percent. No visible errors, no exceptions, no crash. The model still answers, just badly.

In April 2026 the same group published GPUBreach, which chains those flips into a root shell by corrupting the page tables and internal state buffers of NVIDIA’s own driver, and manages it even with the IOMMU enabled, because it no longer attempts an unauthorised DMA access but manipulates the driver’s state instead. The affected GPUs are Ampere-generation parts with GDDR6; the tested patterns produced no flips on GDDR6X, HBM2e or HBM3, though the authors themselves warn that susceptibility depends on the specific die and platform, not on the product family label.

What is left to do

Rowhammer is not fixed by a software patch. What works today: real end-to-end ECC on servers, system-level ECC on GPUs that allow it, more aggressive refresh policies in BIOS wherever there is headroom, and not sharing physical memory between tenants who do not trust each other. What does not work is blind trust: every new mitigation (TRR, PRAC, ODECC) has been sold as final and has lasted a couple of years. The lesson from 2025 is simple and annoying: vendors do not publish the real threshold at which their cells start to fail, and that number only belongs to whoever sits down to measure it.