Rowhammer: Flipping Bits You Never Touched

The bit that leaks: how DRAM remembers and forgets

A DRAM bit is the simplest storage element imaginable: one transistor and one capacitor (a “1T1C” cell). A charged capacitor is one logical value; a discharged one is the other. But a capacitor is a leaky bucket — charge drains through the access transistor and the substrate within milliseconds. To keep data alive, the memory controller refreshes every cell on a fixed schedule: read the row, sense whether it was charged, and write it back at full strength. JEDEC fixes this retention window at 64 ms (32 ms at high temperature), delivered as 8,192 refresh commands spaced roughly tREFI ≈ 7.8 µs apart.

The invariant Rowhammer breaks is this retention guarantee: every cell must hold its value until its next scheduled refresh. Cells are organized into a 2D grid inside a bank — rows share a wordline, columns share a bitline. To read any byte, the controller issues an ACTIVATE that raises the target row's wordline and copies the whole row into a row buffer; a PRECHARGE then closes it before another row can open. That wordline is the weapon: every ACTIVATE swings its voltage, and in a chip built at ~20 nm the aggressor wordline runs only tens of nanometers from its neighbors' storage capacitors.

Hammering: forcing the disturbance

To hammer, an attacker must issue ACTIVATE on one row over and over — hundreds of thousands of times — before the 64 ms window elapses. Two obstacles stand in the way. First, the cache: a normal load is served from L1/L2/L3 and never reaches DRAM. Native code defeats this with the CLFLUSH instruction (flush the line after each access) or non-temporal stores; JavaScript, which has neither, instead builds cache-eviction sets that thrash the line out of cache between accesses. Second, the row buffer: if the aggressor row is already open, the access is a cheap row-buffer hit and no ACTIVATE is issued. So the attacker alternates between two addresses that map to the same bank but different rows, forcing a row-buffer conflict — PRECHARGE, ACTIVATE, repeat — on every access.

The activation budget is generous. A row cycle (tRC) takes roughly 45–50 ns, so in 64 ms one bank can absorb well over a million activations — far above the ~139,000 that flipped the most vulnerable module in the original 2014 study. Double-sided hammering is the killer variant: put the victim in row N and pound both N−1 and N+1, doubling the coupling from both sides and slashing the required count. To find those physically adjacent rows an attacker must know the DRAM address mapping (which physical-address bits pick channel, rank, bank, and row), reverse-engineered by timing row-buffer conflicts (the DRAMA technique, Pessl et al., 2016).

The physics of the flip

Why does an adjacent cell lose its bit? Repeatedly toggling the aggressor wordline couples into the victim through several mechanisms at once: capacitive coupling between neighboring wordlines and bitlines, electromagnetic interference, and charge injected into the silicon substrate (hot-carrier effects) that migrates toward nearby storage nodes. Each ACTIVATE nudges a little charge across the victim's capacitor. Accumulate enough nudges before the next refresh and the cell's voltage crosses the sense-amplifier threshold — the bit reads as its opposite. Whether a given cell flips 1→0 or 0→1 is deterministic per cell, fixed by whether the manufacturer wired it as a “true-cell” (charge = 1) or “anti-cell” (charge = 0).

Density is destiny here. As DRAM shrank from 40 nm toward sub-20 nm, cells moved closer, capacitors got smaller, and the charge margin per bit collapsed — so newer chips flip with fewer hammers, not more. Two twists sharpen the threat. Half-Double (Google, 2021) showed the disturbance reaches distance-2 neighbors, so hammering row N and lightly touching N+1 can flip N+2 — partly because a defense's own extra refreshes act as hammers. And RowPress (Luo et al., ISCA 2023) found that simply keeping the aggressor row open for a long time — not just toggling it — induces flips with dramatically fewer activations, a complementary disturbance the industry had not modeled.

From analog fault to root: aiming the flip

A random flip somewhere in gigabytes of RAM is useless; a flip in the right bit is catastrophic. The canonical target is a page-table entry (PTE) — the small record that maps a virtual page to a physical frame and carries its permission bits. In Mark Seaborn and Thomas Dullien's 2015 Project Zero exploit, the attacker sprays memory with page tables until one lands in a hammerable row, then flips a PTE bit so that a page table points at attacker-controlled memory. Owning a page table means the process can remap any physical frame writable — including the kernel's own — which is total privilege escalation. Their second exploit escaped Google's Native Client sandbox by flipping bits inside already-validated sandboxed instructions to forge an unchecked indirect jump the validator had signed off on.

Landing the victim data on a vulnerable cell is memory templating and massaging: first profile the machine to catalog which offsets flip and in which direction, then coax the operating system into placing a sensitive object (a PTE, an RSA key, an authorized_keys entry) onto exactly that physical cell. Flip Feng Shui (Razavi et al., 2016) did this across virtual machines, abusing memory deduplication to share the victim VM's public-key page with the attacker, then hammering a single bit to weaken the key so it could be trivially factored. RAMBleed (2020) went further and used Rowhammer as a read primitive: because a victim cell's value biases whether a neighbor flips, observing the flips leaks the victim's secret — it recovered an OpenSSH RSA key without ever writing to it.

Delivery vectors: from JavaScript to the wire

Rowhammer's reach is what alarms defenders. Rowhammer.js (Gruss, Maurice, Mangard, 2016) proved the attack needs no native code, no special instructions, and no privileges — just the timing and cache behavior available to sandboxed JavaScript in a browser, using eviction sets in place of CLFLUSH and large typed arrays to guess physical adjacency. GLitch (2018) hammered from the GPU via WebGL. On phones, Drammer (2016) got deterministic flips by requesting physically contiguous buffers from Android's ION allocator, defeating ASLR-style unpredictability.

Most striking, the attacker need not run on the target at all. Throwhammer (2018) hammered a remote server's memory through one-sided RDMA reads over a fast network, and Nethammer showed that even ordinary packet floods — which touch uncached kernel network buffers — can induce flips. These vectors turn a physics quirk into a genuinely remote threat and mean the mitigation cannot live only in the application layer; it has to live in the memory hardware itself.

Defenses — and why each one has been broken

Doubling the refresh rate (64→32 ms) halves the window to accumulate charge, but it costs power and bandwidth and does not help against modules that flip in well under 32 ms — a stopgap, not a cure. Target Row Refresh (TRR) is the industry's main hardware answer: a sampler in the memory controller or DRAM chip watches for rows being activated abnormally often and proactively refreshes their neighbors. But TRR tracks only a limited number of aggressors. TRRespass (2020) and especially Blacksmith (Jattke et al., 2021) used many-sided and non-uniform, frequency-modulated hammering patterns that spread activations across more rows than the sampler can hold — Blacksmith flipped bits on all 40 TRR-protected DDR4 modules it tested. Researchers reverse-engineered these samplers with tools like U-TRR, using retention failures as a microscope.

ECC memory raises the bar but is not immune. Server DRAM typically uses SECDED — a (72,64) Hamming code with 8 check bits per 64-bit word that corrects one flipped bit and detects two. Rowhammer can flip three or more bits in a single word, which may be miscorrected or merely crash the machine; ECCploit (2019) even used the extra latency of a correction as a timing side channel to locate flips and craft multi-bit patterns ECC can't catch. The current frontier is DDR5, which adds on-die ECC, Refresh Management (RFM), and per-row activation counting to bound how many times a row can be hammered before a mandatory neighbor refresh — a real improvement, though history counsels caution. Software mitigations (ANVIL's performance-counter detection, CATT and allocator guard rows that keep attacker and victim memory physically apart) help but cannot fully substitute for fixing the silicon. Rowhammer remains an open arms race precisely because its root cause — charge leaking between ever-denser cells — gets worse with every process shrink.

Rowhammer variants: hammering strategy, delivery vector, and what each one defeats

Technique / attack	Year & authors	Vector	Key idea
Single-sided hammering	2014, Kim et al.	Native code (CLFLUSH)	Toggle one aggressor row against a bank; earliest, weakest
Double-sided hammering	2015, Seaborn & Dullien (P0)	Native / PTE spray	Sandwich the victim: hammer rows N−1 and N+1 to flip N — far higher yield
Rowhammer.js	2016, Gruss et al.	JavaScript in a browser	Cache-eviction sets replace CLFLUSH — no special instructions needed
Drammer	2016, van der Veen et al.	Android / ARM	Deterministic flips via contiguous (ION) allocations on mobile
Throwhammer / Nethammer	2018, Tatar / Lipp et al.	Network (RDMA / packets)	Remote hammering — no code execution on the target at all
TRRespass / Blacksmith	2020–2021, Frigo / Jattke et al.	Native, TRR-enabled DDR4	Many-sided, non-uniform patterns overrun Target Row Refresh