Bits That Flip on Their Own: Rowhammer and the Physical Weakness of Computer Memory

The Hook: An Attack That Needs No Bug in the Code

Most of the security flaws we talk about are errors in thinking. A programmer forgot to validate an input; a protocol permits a state no one anticipated; a library trusts data it should not have trusted. Such errors can be found, reported, patched. The software gets corrected, the hole closes, and the world moves on.

Rowhammer is of a different kind. Here no line of code is faulty. The operating system does exactly what it should, the memory management works correctly, the access permissions are cleanly set. And yet an unprivileged program — one holding no special rights, perhaps even running as JavaScript inside a web page — can break out of its assigned memory region and reach into foreign memory it should never have been able to touch. It does this not by reading a forbidden address, but by reading its own, entirely legal memory cells so fast and so often that in the neighboring cells individual bits flip over. The attacker writes nowhere it is not allowed to. It merely knocks on a wall until, on the other side, something falls to the floor.

This physical side effect of the knocking — hammering, hence the name — turns a property of the hardware into a weapon. It breaks perhaps the most fundamental assumption of all of computer security: that a memory access changes only the cell it addresses and leaves all the others in peace. With Rowhammer this is no longer true. Memory becomes leaky — not in a figurative sense, but in the literal, electrical one.

For someone like Sven — a Senior AI Engineer with one foot in cloud architecture and one in IT security — Rowhammer is instructive for two reasons. First, it shows how a purely physical property, one the memory manufacturers accept for the sake of cost, transforms into a concrete security problem against which no amount of correct software is immune. Second, the twelve-year history of Rowhammer is a model study of an arms race: every countermeasure the industry deployed was broken by research, every new memory generation meant to solve the problem fell again. This article takes you the whole distance — from the physics of the memory cell through the first discovery in 2014 and the transformation into real attacks, all the way to the fall of the current DDR5 generation in 2025.

Part 1: How Working Memory Functions — and Why It Is Forgetful by Nature

To understand why bits flip, you have to know how they are stored in the first place. The working memory of modern computers is DRAM — Dynamic Random Access Memory. The word "dynamic" is the key to the whole problem.

A single DRAM memory cell is astonishingly simple: it consists of exactly one tiny capacitor and one transistor acting as a switch. The capacitor holds an electric charge — charged, the cell stands for a one; discharged, for a zero (or vice versa, depending on convention). This frugality — one capacitor, one transistor per bit — is why DRAM is cheap and dense, and why a modern memory stick fits many billions of bits onto a few square centimeters.

The price of this simplicity is forgetfulness. A capacitor of this size does not hold its charge. It is like a bucket with a fine leak: within fractions of a second the charge seeps away, and the stored information would fade. That is why DRAM must be refreshed. At regular intervals the memory controller reads out every cell and immediately writes its value back, topping up the bucket before it runs dry. The JEDEC standard mandates that every row must be refreshed at least once within a refresh window of 64 milliseconds (32 ms for DDR5 under certain conditions). It is precisely this constant, hidden refilling that makes memory "dynamic."

The cells are not arranged at random but organized in a grid of rows and columns, like a vast chessboard. To read data, the controller first activates an entire row: it opens the transistors of that row, causing the capacitors' charges to flow onto the so-called bit lines, where they are captured by sense amplifiers. Only then can an individual column within that row be read out. This "opening" of a row is called activation (ACT), the subsequent closing precharge. The crucial point: every activation sends a small electrical pulse through the row. And that pulse does not leave the neighbors untouched.

Part 2: The Discovery — When the Knocking Passes Through the Wall

In 2014, a research group around Yoongu Kim (then at Carnegie Mellon University, together with Intel Labs) published, at the architecture conference ISCA, a paper with the programmatic title "Flipping Bits in Memory Without Accessing Them." This was no mere theory: the group tested 129 commercial DDR3 modules from various manufacturers and found that the great majority exhibited one and the same uncanny behavior.

The effect goes like this: if you activate a particular row in memory very often and very rapidly in succession — hundreds of thousands of times within a single 64-millisecond refresh window — then, with high probability, individual bits flip in the immediately adjacent rows. The repeatedly activated row is called the aggressor row, the affected neighbor the victim row. Not a single access ever hits the victim row — and yet its contents change.

The physical cause is a phenomenon aptly termed read disturbance. Every activation of a row produces electrical effects — capacitive coupling between neighboring word lines, leakage currents, the migration of individual electrons — that pull a tiny bit of charge from, or add it to, the capacitors of the neighboring row. A single knock does nothing: by the next refresh the disturbance has long since evened out. But if you hammer hundreds of thousands of times before the saving refresh arrives, the tiny disturbances accumulate until a victim cell slips over the threshold and its value is misread by the hardware. The bit has flipped.

Kim and colleagues immediately recognized the root cause: miniaturization. To make DRAM ever denser and cheaper, manufacturers pack the cells ever closer together. The smaller the spacing between rows, and the less charge a shrunken cell stores, the more strongly neighboring rows couple electrically, and the more susceptible the memory becomes to exactly these disturbances. Rowhammer is therefore not a manufacturing defect of particular batches but a structural consequence of progress — the price of packing memory ever more densely. I am of the opinion that it is precisely this point that makes Rowhammer so disquieting: the force that makes memory vulnerable is the very same one that makes it cheap and powerful.

At the time of publication this was still a reliability and engineering question — a "disturbance error." That within a year it would become a sharp weapon almost no one foresaw.

Part 3: From Fault to Attack — the Art of Hitting the Right Bit

A randomly flipping bit somewhere in memory is a nuisance. A deliberately flipping bit at a security-critical location is a break-in. The step from the former to the latter was taken in 2015 by the team at Google Project Zero, namely Mark Seaborn and Thomas Dullien. In a widely noted blog post they showed that Rowhammer can be exploited from an unprivileged program to fully take over the system — and delivered two exploits at once.

The first escaped the sandbox of Google Native Client (NaCl), a technique meant to run untrusted native code safely in the browser. The second, the more fundamental one, gave an ordinary Linux process kernel privileges and thereby access to all of physical memory. With that the proof was made: Rowhammer is not an academic curiosity but a tool for privilege escalation.

How do you hit the right bit on purpose? Three ingredients make the difference.

First, double-sided hammering. Instead of working only one aggressor row, the attacker hammers both rows that sandwich a victim row — the one above and the one below. The disturbances from both directions add up, and the bits in the pinched victim row flip far more reliably and quickly.

Second, flushing the cache. For the activations to reach the physical DRAM at all, the processor must not serve the accesses from its fast cache. The attacker therefore has to ensure that every read actually reaches memory — for example with the clflush instruction, with targeted cache eviction, or, when none of that is available, with non-cached memory.

Third — and this is the real art — memory massaging (or memory templating). A flipped bit is only useful if something valuable lies at the victim location. The attacker therefore first searches systematically for memory cells that flip reliably at all (building a "map" of the wobbly bits), and then, by cleverly allocating and freeing memory, coaxes the operating system into placing a critical data structure exactly onto such a wobbly cell. The classic case is a page-table entry (PTE) — an entry in the page table with which the operating system maps virtual to physical addresses and manages access rights. If the right bit flips in a PTE, the attacker can redirect one of their own memory pages to a foreign physical page — for instance to another page table — and thereby gain write access to all of memory. A flipped bit becomes control of the machine.

A particularly elegant and disquieting variant was delivered in 2020 by the researchers behind RAMBleed (Andrew Kwong, Daniel Genkin, Daniel Gruss, and Yuval Yarom). Their insight: Rowhammer need not write to do harm — it can also read. Whether and when a bit in the victim row flips depends statistically on the values of the neighboring bits in the aggressor rows. By observing which bits flip under which conditions, RAMBleed infers, in reverse, the unknown contents of foreign memory rows — without ever reading them. With this the authors extracted a secret RSA key of an OpenSSH server from memory. Rowhammer thereby became, from a tool of integrity violation (altering data), also one of confidentiality violation (stealing data).

Part 4: The Arms Race — Every Defense Fell

Once the scale became clear, the industry responded with a series of countermeasures. The history of these measures is at the same time the history of their failure — a race in which the defenders were always one step behind.

The doubled refresh rate. The obvious idea: if the disturbances accumulate between two refreshes, then refresh more often. Many BIOS makers halved the refresh interval to 32 ms. This makes the attack harder but does not eliminate it — faster hammering techniques manage the necessary activations even in the halved window. And more frequent refreshing costs power and performance, because during a refresh the memory is unavailable for actual data.

Error correction (ECC). Server memory often contains ECC (Error-Correcting Code), which can detect and correct a single flipped bit per memory word. For a long time ECC was regarded as broad protection. But in 2018 the work ECCploit (Lucian Cojocar and colleagues at VUSec) showed that ECC is no panacea: if two or more bits flip simultaneously, ECC is overwhelmed; and through subtle timing differences in the correction one can even work out where bits have flipped. ECC raises the bar considerably but is no bulwark. The connection to quantum error correction, which I have described elsewhere in the vault, is enticing: in both worlds the point is to defend information against physical noise — only there the "attacker" is nature, here a human deliberately provoking the noise.

Target Row Refresh (TRR). The most sophisticated answer, introduced at scale with DDR4, is TRR. The idea: the memory (or the controller) observes which rows are being activated unusually often, thereby detects an ongoing attack, and preemptively refreshes the endangered neighbor rows before their bits can flip. TRR was hailed as the breakthrough that would finally put Rowhammer to rest. Manufacturers declared their DDR4 modules "Rowhammer-free."

That declaration did not hold for long. In 2020 TRRespass (Pietro Frigo and colleagues at VUSec and ETH Zurich) showed that TRR has a decisive weakness: it can only keep track of a limited number of aggressor rows at once. Their attack, many-sided hammering, distributes the activations across many aggressor rows simultaneously and thereby overloads the TRR's counters — while leaving enough rows unobserved to flip bits. Using a fuzzing approach, TRRespass again found vulnerable patterns in many of the tested "protected" DDR4 modules.

In 2021 Blacksmith (Patrick Jattke and colleagues of the COMSEC group at ETH Zurich, published at IEEE S&P 2022) went further still. The authors recognized that earlier attacks hammered uniformly — all aggressors at the same frequency. TRR had learned to recognize such regularity. Blacksmith therefore deliberately searched the space of non-uniform patterns, in which different aggressor rows are worked at different frequencies, phases, and amplitudes — thinking in the "frequency domain." The result: Blacksmith flipped bits on all 40 tested DDR4 modules and exposed TRR definitively as inadequate.

Two further techniques rounded out the picture. Half-Double (Google, 2021) showed that the disturbance reaches not only the direct neighbors but, via a coupled intermediate row, also the next-but-one row — Rowhammer acts over greater distances than thought, which defeats many TRR implementations that protect only the immediate neighbors. And RowPress (Haocong Luo and colleagues, ETH Zurich, ISCA 2023) turned the attack around: instead of quickly opening and closing a row again and again, RowPress keeps it open for longer. That too increases the disturbance of the neighbors — with drastically fewer activations, which undercuts many defenses based on activation counting.

The pattern is unmistakable: every deployed countermeasure was broken by research. Not because the engineers were incompetent, but because the defense was, until now, reactive and heuristic — it recognized known attack patterns instead of solving the underlying physical problem in a principled way.

Part 5: Phoenix — the Fall of DDR5 in 2025

With the DDR5 memory generation everything was supposed to get better. It brings a markedly more sophisticated on-die ECC (error correction directly in the DRAM chip) and further-developed, more complex TRR mechanisms. At first this seemed to work: ZenHammer (Patrick Jattke and colleagues, ETH Zurich, USENIX Security 2024) managed, on AMD's Zen platforms, to flip bits on a DDR5 module for the very first time — but only on a single one of ten tested sticks. DDR5 was considered a hard nut.

That hope shattered in September 2025 with Phoenix — again from the COMSEC group at ETH Zurich, in collaboration with Google, tracked under CVE-2025-6202 (CVSS 7.1). Phoenix went after the DDR5 modules of SK Hynix, currently the largest DRAM manufacturer in the world, and laid bare their TRR protection through painstaking reverse engineering.

Using FPGA-based experiments, the researchers reconstructed when exactly the TRR mechanism samples the activated rows to detect suspicious activity. In doing so they stumbled upon a surprising structure: the sampling cycle repeats not, as previous attacks assumed, after 16, but only after 128 refresh intervals (tREFI) — eight times longer. And within this long cycle they found blind spots: certain refresh intervals in which the protection samples barely or not at all. Into precisely these gaps they placed their two new hammering patterns — one over 128, a longer one over 2608 refresh intervals.

Such long patterns carry a practical problem: they span thousands of refresh operations, and the attack must stay precisely synchronized with the memory's internal refresh clock across that whole distance. Lose the beat and the effect fizzles. Earlier synchronization methods, including ZenHammer's, failed at this length. Phoenix's decisive innovation is therefore a self-correcting synchronization: rather than trying to detect every single refresh operation flawlessly, it exploits the periodicity of the refreshes and automatically realigns the hammering pattern the moment it notices a refresh was missed. In this way the attack stays on the beat across thousands of intervals.

The results are sobering. Phoenix flipped bits on all 15 tested DDR5 modules from SK Hynix (manufacturing dates from late 2021 to late 2024) — on average several thousand flipped bits per stick with the shorter pattern. And the flips were genuinely exploitable: the authors demonstrated three practical attacks — manipulating page-table entries for an arbitrary read/write primitive (all modules vulnerable), stealing an RSA-2048 key of a co-resident virtual machine to break SSH authentication (73% of the vulnerable modules), and manipulating the sudo binary for local privilege escalation to root (33%). On a commodity PC with default settings, full takeover with root privileges succeeded in as little as 109 seconds.

Two details deserve particular attention. First: on-die ECC does not stop Phoenix. The chip-internal error correction fixes bits only on writing or at large time intervals — hammer for long enough and errors accumulate faster than ECC clears them. Second: the only reliable protection the researchers found for existing modules is the old idea in intensified form — tripling the refresh rate (tREFI ≈ 1.3 µs), which stopped Phoenix in their tests but costs around 8.4% performance. The authors disclosed Phoenix responsibly: they reported the finding on 6 June 2025 through the Swiss NCSC to SK Hynix, the CPU makers, and major cloud providers; the embargo ran until 15 September 2025. The full publication appears at IEEE S&P 2026.

Part 6: Why the Problem Does Not Go Away

Twelve years after Kim's discovery, Rowhammer is not solved but worse. There is a deep, uncomfortable reason: the cause is physics, and physics pulls in the wrong direction. Every new memory generation packs the cells more densely, shrinks the structures, and stores less charge per bit — and each of these steps, which make memory cheaper and faster, intensifies the coupling between rows and thereby the susceptibility. Rowhammer is the shadow of miniaturization.

Aggravating this is an economic and structural factor: the built-in protection sits inside the DRAM chip and cannot be updated after shipping. A software hole is patched in hours; a vulnerable memory stick can only be replaced. Billions of already-installed modules will keep their weakness across their entire lifetime. And because the countermeasures so far are heuristic — they recognize known patterns instead of solving the problem at its root — every one of them turned out, in hindsight, to be circumventable.

What helps, then? A bundle of approaches, none of them sufficient alone:

Principled counters instead of heuristics. The most promising direction is DRAM-internal mechanisms that reliably count and protect every frequently activated row instead of guessing — such as the approach specified by JEDEC for DDR5, PRAC (Per Row Activation Counting), which gives each row a true activation counter. I am of the opinion that only such principled methods, not based on pattern recognition, can win the race in the long run — anything else practically invites the next clever attack.

Increased refresh rate. As seen with Phoenix: dearly bought but effective. A stopgap for existing hardware, not a permanent state.

Software-side isolation. At the system level one can limit the damage by physically separating critical data structures from unprivileged memory (guard rows, domain-aware memory allocation), so that an attacker cannot even get near worthwhile victim rows. This does not fix Rowhammer but raises the cost of exploitation.

Awareness in the threat model. For cloud operators — and thus for Sven's daily work — the most important lesson is: in a multi-tenant environment, foreign workloads share the same physical memory chips. Phoenix showed that an attacker in one virtual machine can steal the RSA key of another VM on the same host. The isolation between tenants, which one likes to take for granted, does not end at the software boundary of virtualization but reaches all the way down into the physics of the memory cell.

A Timeline of the Race

The Central Takeaway

The practical core of this article can be condensed into a single, uncomfortable sentence: Security does not end at the software boundary — it reaches all the way down into the physics of the hardware. Rowhammer is the reminder that our entire security architecture rests on a tacit assumption that is false: that a memory access affects only the addressed cell. Where that assumption flips, the bits flip.

For Sven's work — in cloud architecture, in security design, in operating systems that handle sensitive data — the transferable lesson is twofold. First: audit your threat model for physical assumptions. If you run foreign workloads on shared hardware, the isolation between them is only as strong as the weakest physical coupling in the system — and that lies beyond anything a software patch can ever reach. For highly sensitive keys and secrets, dedicated hardware, an HSM, or increased memory hardening is not paranoia but a warranted response to a proven class of attack. Second, more generally: treat the response of heuristic defenses with skepticism. The twelve-year history of Rowhammer is one long lesson that defenses which recognize known patterns, instead of solving the underlying problem in a principled way, are almost always circumvented in hindsight. This rule of thumb holds far beyond memory — for intrusion detection, for spam filters, for any defense that relies on signatures rather than invariants.

Reflection Question

Rowhammer exploits the fact that a physical side effect breaks a logical boundary we held to be absolute. Where in your own systems do you implicitly rely on an "isolation" that is in truth only a convenient assumption — shared memory, shared CPU caches, shared network paths, shared physical hardware — and what would change in your architecture if you assumed that every shared resource is a potential side channel?

Cross-References in the Vault

• When the Processor Guesses Too Much: Spectre, Meltdown, and the Sin of Speculative Execution – the related family of microarchitectural attacks: there speculative execution leaks secrets through a cache side channel, here a physical disturbance breaks memory isolation. Both show how hardware optimizations turn into security holes.
• Order from Noise: Quantum Error Correction and the Road to a Fault-Tolerant Quantum Computer – error correction as a defense of information against physical noise; with Rowhammer the noise is deliberately provoked by an attacker and ECC is intentionally defeated.
• The Key That Dies After Every Message: The Signal Protocol, the Double Ratchet, and the Art of End-to-End Encryption – the strongest cryptography is useless if the key sits in plaintext in memory and can be hammered out of it — as demonstrated by RAMBleed and Phoenix. The endpoint as the weak spot.
• Betting on a Stranger's Code: Firecracker microVMs and the End of the Container-versus-VM Dilemma – tenant isolation in the cloud: Firecracker hardens the software boundary, yet Phoenix shows that the physical memory coupling beneath it remains an attack surface of its own.

Sources

• Y. Kim, R. Daly, J. Kim, C. Fallin, J. H. Lee, D. Lee, C. Wilkerson, K. Lai, O. Mutlu: Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors, ISCA 2014. https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf
• M. Seaborn, T. Dullien: Exploiting the DRAM rowhammer bug to gain kernel privileges, Google Project Zero, 2015. https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
• P. Frigo, E. Vannacci, H. Hassan, V. van der Veen, O. Mutlu, C. Giuffrida, H. Bos, K. Razavi: TRRespass: Exploiting the Many Sides of Target Row Refresh, IEEE S&P 2020. https://download.vusec.net/papers/trrespass_sp20.pdf
• P. Jattke, V. van der Veen, P. Frigo, S. Gunter, K. Razavi: BLACKSMITH: Scalable Rowhammering in the Frequency Domain, IEEE S&P 2022. https://comsec.ethz.ch/wp-content/files/blacksmith_sp22.pdf
• H. Luo, A. Olgun, A. G. Yağlıkçı, Y. C. Tuğrul, S. Rhyner, M. B. Cavlak, J. Lindegger, M. Sadrosadati, O. Mutlu: RowPress: Amplifying Read Disturbance in Modern DRAM Chips, ISCA 2023. https://arxiv.org/abs/2306.17061
• A. Kwong, D. Genkin, D. Gruss, Y. Yarom: RAMBleed: Reading Bits in Memory Without Accessing Them, IEEE S&P 2020. https://rambleed.com/
• ETH Zurich COMSEC & Google: Phoenix: Rowhammer Attacks on DDR5 with Self-Correcting Synchronization (CVE-2025-6202), IEEE S&P 2026. https://comsec.ethz.ch/research/dram/phoenix/
• O. Mutlu, J. S. Kim: RowHammer: A Retrospective, IEEE TCAD 2019. https://arxiv.org/abs/1904.09724

Note: This article reflects the verifiable, scientifically established state of knowledge. Where personal assessments enter, they are marked with "I am of the opinion that ..."

← All articles