Your RAM is supposed to be one of the safest parts of your computer. It doesn’t have persistent storage. It can’t be “infected” the way a hard drive can. When the power goes off, everything in it disappears. For a long time, security people kind of assumed RAM was just… fine. Not the thing to worry about.
That assumption was wrong.
Rowhammer is a hardware-level attack that breaks the fundamental promise of memory isolation — the idea that one program can’t touch another program’s data. And the weird part? It doesn’t exploit a bug in any software. There’s no malformed input, no buffer overflow, no bad code to patch. The attack works by doing something completely normal: reading memory. Just reading it, over and over and over, until the hardware itself breaks down and starts flipping bits it’s not supposed to flip.
What DRAM Actually Is (and Why It’s Fragile)
Before getting into how the attack works, it helps to understand what modern RAM actually is, physically.
DRAM — Dynamic Random Access Memory — stores each bit of data as a tiny electrical charge in a capacitor. Millions of these capacitors are packed together on a single chip. They’re arranged in a grid of rows and columns. Each row holds a huge number of bits — typically in the thousands. When you access a memory address, the memory controller opens the relevant row, reads or writes the data, and closes it again.
The problem is the “dynamic” part. DRAM capacitors leak charge. Slowly but constantly. If you don’t refresh them, the charge drains away and your data corrupts. So memory controllers refresh every row thousands of times per second — a process called the refresh cycle. In most systems today, this happens once every 64 milliseconds.
And here’s the key thing: these rows are packed extremely close together on the chip. We’re talking about physical distances that are now smaller than a few dozen nanometers. At that scale, the electrical activity in one row can actually influence the charge in neighboring rows. It’s a physical phenomenon called electromagnetic coupling. The cells are so close together that accessing one row repeatedly causes tiny voltage disturbances in the rows next to it.
Normally, this doesn’t matter. You’d access a row a few times, move on, and the refresh cycle would fix any small disturbances before they became a problem.
But what if you accessed the same row not a few times, but millions of times? What if you could hammer the same row so fast that the refresh cycle couldn’t keep up?
That’s rowhammer.
How the Attack Actually Works
The core idea is simpler than it sounds. An attacker runs a program that repeatedly reads from two specific memory rows — rows that are physically adjacent to a target row they want to corrupt. This is called double-sided rowhammering. By hammering both the row above and the row below the target, the disturbance effect is amplified from both directions.
The key challenge is speed. To flip a bit before the refresh cycle can fix it, the attacker needs to access the same rows tens of millions of times per second. On modern CPUs, memory reads are usually cached — the CPU stores recently accessed data in the L1, L2, or L3 cache so it doesn’t have to go all the way to DRAM every time. If the attack data stays in cache, it never actually hammers the DRAM.
So the attacker has to defeat caching. There are a few ways to do this. One is the clflush instruction on x86 processors, which explicitly flushes a cache line back to memory. Another is to access enough different memory addresses that the cache fills up and evicts the target lines automatically. Both approaches let the attacker force actual DRAM accesses at high frequency.
The flip itself is probabilistic. Not every attempt flips a bit. But given enough time and the right conditions, bit flips happen. And when they do, the results can be catastrophic.
From a Bit Flip to Root Access
A random bit flip sounds like just corruption. Why is this a security problem?
Because memory isn’t random. Data in RAM has structure. Page tables map virtual addresses to physical memory. Permission bits control what processes can read or write. Cryptographic keys sit in memory during operations. If an attacker can flip the right bit in the right location, they can escalate their privileges from an unprivileged process to full system control.
The first real-world Rowhammer exploit came in 2015, from researchers at Google Project Zero — Mark Seaborn and Thomas Dullien (who goes by Halvar Flake online). They published two working exploits. One of them broke out of the Chrome Native Client sandbox. The other got kernel privileges on Linux from an unprivileged process. Both ran from user space. No kernel bugs were involved. No CVE for a software flaw — just physics.
The way the privilege escalation worked is worth understanding. The attacker’s process allocates a bunch of memory and then hammers rows near it. The goal is to flip a bit in a page table entry — a data structure the kernel uses to manage which physical memory pages belong to which process. If the attacker can flip the right bit, they can make their page table point to a physical page they don’t own. From there, they can write to it and use it as a stepping stone to map any physical memory they want, including kernel memory.
This is not theoretical. Seaborn and Dullien ran it on actual hardware.
The Variants Keep Coming
The 2015 paper was the start, not the end.
Flip Feng Shui (2016) — researchers from VU Amsterdam showed that you could target specific data in memory by exploiting memory deduplication in hypervisors. Cloud VMs share physical memory pages if they contain identical content. The attacker uses Rowhammer to flip bits in a shared page, corrupting data in another VM they have no access to. On a shared cloud host. That’s the kind of thing that should make people nervous.
Rowhammer.js (2015/2016) — a JavaScript-based variant that runs entirely in the browser. No native code, no special permissions. Daniel Gruss and his team at Graz University of Technology showed that JavaScript, running in a normal web page, could perform enough memory accesses to trigger bit flips on some systems. The attack was slow and unreliable, and browsers later added mitigations, but it proved the concept could reach untrusted execution environments.
Throwhammer (2018) — bit flips triggered over a network using RDMA (Remote Direct Memory Access), without the attacker running any code on the target machine at all. Just network packets hammering memory remotely.
Nethammer (2018) — similar idea, different angle. Researchers showed that sending crafted network packets could cause the target system’s kernel or driver to access certain memory repeatedly, triggering Rowhammer without any local code execution.
Blacksmith (2021) — this one was annoying. By 2020, most DRAM manufacturers had added a hardware defense called Target Row Refresh (TRR), which was supposed to detect rows being accessed unusually often and refresh their neighbors proactively. Researchers at ETH Zurich and VU Amsterdam built Blacksmith, a fuzzer that found non-uniform hammering patterns — accessing rows in irregular, asymmetric sequences — that bypassed TRR completely. So the main hardware defense that the industry thought had solved rowhammer? Not solved.
RowPress (2023) — a related but distinct technique from researchers at ETH Zurich. Instead of accessing rows rapidly many times, RowPress keeps a row open for a long time during each activation. Leaving a row open for microseconds instead of nanoseconds causes more disturbance to neighboring rows per access. Some systems that were resistant to classic Rowhammer were vulnerable to RowPress. The attack space just keeps expanding.
Who Is Actually at Risk?
This is where it gets complicated.
Consumer DDR4 RAM is generally more resistant than older DDR3, but not immune. DDR5 introduced built-in on-die ECC (Error Correcting Code) in many modules, which can catch single-bit flips. But ECC corrects errors, it doesn’t necessarily prevent the hammering itself, and multi-bit flips can still get through depending on the ECC implementation.
Server-grade ECC RAM is better protected but still not a complete defense, as researchers have shown attacks that work around ECC.
Mobile devices are a different story. LPDDR memory in phones has shown vulnerability. A 2016 paper by Kaveh Razavi and others from VU Amsterdam demonstrated Rowhammer attacks on Android phones — flipping bits in page tables, getting root. Samsung, Qualcomm, and others were all affected at the time.
Cloud environments are especially uncomfortable because multiple tenants share physical hardware. The Flip Feng Shui work made clear that VM isolation assumptions don’t fully hold against hardware-level attacks.
The honest answer to who’s at risk: a lot of systems, to varying degrees. The attack is hard to pull off reliably, but “hard” doesn’t mean “impossible,” and the research consistently shows that defenses thought to be solid are later found to have gaps.
Why Software Can’t Really Fix a Hardware Problem
This is what makes Rowhammer different from most security vulnerabilities.
A buffer overflow can be fixed with better code. A SQL injection disappears when you sanitize your inputs. These are software problems with software solutions.
Rowhammer is a physical property of how DRAM works at scale. The cells are close together, they leak charge, and hammering induces disturbances. No amount of code changes that.
There are software-level mitigations. Operating systems have tried things like memory isolation, page table protection, making certain pages read-only, and randomizing memory layout so an attacker can’t predict where page tables will be. The Linux kernel added defenses after the 2015 exploits. Browsers reduced timer resolution and added jitter to slow down timing-based attacks. Intel added hardware performance counter monitoring to detect unusual memory access patterns, though this has limits.
The one mitigation that actually addresses the root cause is hardware-level — specifically, using DRAM that either has very low disturbance error rates, or that implements a solid form of Target Row Refresh that can’t be bypassed with non-uniform patterns. The JEDEC standard (the industry body that defines DRAM specifications) added requirements for TRR. But as Blacksmith showed in 2021, those requirements weren’t tight enough to stop determined researchers.
DDR5’s mandatory on-die ECC helps but isn’t a complete solution. Hardware vendors are slowly improving, but the attack surface is huge — there are billions of vulnerable DRAM modules in devices right now.
What the Attack Looks Like in Practice
To be concrete: a basic Rowhammer proof of concept on Linux (for educational purposes, the way security researchers write them) looks roughly like this.
The attacker’s process allocates a large chunk of memory — enough to work with several DRAM rows. It identifies two rows to hammer that are physically adjacent to the target row. Physical addresses matter here, not virtual addresses. Getting physical address information usually requires reading /proc/self/pagemap, which on most modern Linux systems requires elevated permissions or a specific configuration. This is actually one of the practical mitigations — restricting /proc/self/pagemap access makes the attack significantly harder to aim.
Then the loop runs: flush the cache line for the two hammer addresses, read both addresses, repeat. As fast as possible. On a modern system, this inner loop might execute 10 to 20 million times per second. After a few seconds, you stop and check whether any bits in the target row have changed.
On vulnerable hardware, some will have.
The gap between “some bits flipped” and “you have root” is where the real exploit engineering happens. That part is hard. But the bit flip part — the physics part — works.
A Hardware Problem That Isn’t Going Away
Here’s the frustrating reality: Rowhammer exists because of a fundamental tension in the semiconductor industry.
Chip manufacturers have been packing more transistors and capacitors into the same physical space for decades. More density means more storage at lower cost. But more density also means cells are closer together, the electromagnetic coupling is stronger, and disturbance errors get worse. ITRS (International Technology Roadmap for Semiconductors) projections from before 2015 actually predicted that disturbance errors would become a problem as process nodes shrank below 20nm. The researchers who published the first Rowhammer paper in 2014 (Kim et al., from Carnegie Mellon and Intel Labs) explicitly noted this.
So this wasn’t entirely surprising to people watching the hardware closely. It just took a while for the security community to connect “disturbance errors are a DRAM reliability problem” to “disturbance errors are a security problem.”
That 2014 paper by Yoongu Kim, Ross Daly, Jeremie Kim, Chris Fallin, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai, and Onur Mutlu is worth reading if you want the low-level detail. It’s on the ACM digital library and has been cited over a thousand times. They tested 129 DRAM modules from three major manufacturers. 110 of them showed disturbance errors under their hammering conditions. That’s 85%.
The problem was always there. People just weren’t looking for it from a security angle.
Where Things Stand Now
As of early 2025, Rowhammer research is still active. The RowPress paper from ETH Zurich (published at USENIX Security 2023) opened new questions about how different hammering strategies interact with different DRAM architectures. There’s ongoing work on DRAM-side defenses, smarter refresh schemes, and better TRR implementations.
DDR5 adoption is growing, and its mandatory on-die ECC does raise the bar. But even DDR5 isn’t fully immune — researchers have shown that with enough bit flips in a single access window, ECC can be overwhelmed or the errors can manifest in ways that still affect system behavior.
The most honest assessment from the research community right now is that the existing defenses reduce the attack surface considerably but don’t eliminate it. The Blacksmith fuzzer from 2021 is still finding bypasses. The RowPress technique from 2023 showed that thinking only about access frequency misses another dimension of the problem.
And in the meantime, billions of devices with DDR3 and older DDR4 RAM — devices that will never be patched because they can’t be patched — are running in data centers, offices, and homes.
Defending Against It
What can you actually do? Realistically, for most people, not much at the hardware level unless you’re buying new equipment.
If you run servers, ECC RAM is worth it — not because it fully stops Rowhammer, but because it catches many single-bit flips that would otherwise be silent data corruption. That’s valuable for reliability, not just security.
OS-level mitigations matter. On Linux, restricting access to /proc/self/pagemap (which was done in kernel version 4.0 with /proc/sys/kernel/perf_event_paranoid changes and later with specific pagemap restrictions) removes a key tool that attacks use to find physical addresses. Huge pages can also be a double-edged sword — they make hammering more effective by keeping more data in a predictable physical layout, and some kernel configurations allocate huge pages by default.
Browser vendors have reduced timer resolution — Google Chrome and Mozilla Firefox both did this around 2018, after Spectre and Meltdown prompted broader concern about timing attacks. High-resolution timers make rowhammer.js-style attacks easier to pull off.
For enterprise environments, memory scrubbing — periodically checking and correcting ECC errors rather than just silently correcting and continuing — gives you visibility into whether your RAM is being hammered or is just degrading. If a specific set of cells shows repeated ECC corrections, that’s worth investigating.
And if you’re evaluating cloud providers, asking about their memory isolation policies and whether they disable memory deduplication for security-sensitive workloads is a reasonable question. Some providers explicitly disable KSM (Kernel Same-page Merging) for this reason.
The Bigger Picture
Rowhammer sits at an uncomfortable intersection of hardware reliability and software security. The security community has spent decades building abstractions — process isolation, virtual memory, privilege levels — that assume the hardware does what it’s told. Rowhammer breaks that assumption without touching any of the software.
It’s not the only attack in this category. Spectre and Meltdown (2018) exploited speculative execution in CPUs in ways that broke isolation between processes. Plundervolt (2019) manipulated CPU voltage to cause targeted computation errors. CLKSCREW (2017) attacked ARM TrustZone by manipulating clock frequencies. Hardware is not a neutral substrate that software safely runs on top of. Hardware has its own failure modes, its own physics, its own interaction effects that the software above it never anticipated.
Rowhammer just happened to be one of the first — and cleanest — demonstrations that a completely normal program doing completely normal things could break fundamental security guarantees through sheer physical persistence.
That’s worth understanding. Not because most people will be rowhammered tomorrow, but because it changed how serious researchers think about the security of computing systems from the ground up.
The hardware matters. It always did. People just forgot to worry about it for a while.