You are not allowed to modify this memory.
The operating system says no. The CPU's memory protection says no. The page table marks the region as belonging to a different process.
So you don't write to it.
Instead, you repeatedly access the memory next to it. Thousands of times per second. You stay entirely within your own allocated region.
And eventually, a bit in the protected memory changes.
No permission was violated. No buffer was overflowed. No kernel bug was triggered. The hardware did it.
That's Rowhammer.
How DRAM Actually Stores a Bit
To understand why this happens, you need a basic picture of how DRAM works at the physical level.
Each bit in DRAM is stored in a cell that consists of a capacitor and an access transistor. The capacitor holds charge. Charge present represents one binary state; charge absent represents the other. The transistor connects the capacitor to a bitline, a wire that runs through the memory array and is used during read and write operations.
Cells are arranged in a grid. Wordlines run horizontally, connecting the transistors of all cells in a row. Bitlines run vertically. To access a row, the memory controller asserts the wordline, which opens all the transistors in that row simultaneously, connecting every cell's capacitor to its corresponding bitline. Sense amplifiers at the end of each bitline then detect and amplify the tiny charge signal.
Bitline Bitline Bitline
| | |
Row A ──[T]─C─ ──[T]─C─ ──[T]─C─
| | |
Row B ──[T]─C─ ──[T]─C─ ──[T]─C─
| | |
Row C ──[T]─C─ ──[T]─C─ ──[T]─C─
T = access transistor, C = capacitor
This physical arrangement is what makes Rowhammer possible. Rows are physically close to each other. The cells are packed tightly.
What Happens When You Activate a Row
When the memory controller accesses a DRAM row, it activates the entire row: the wordline is asserted, all the transistors open, and the capacitors interact with the bitlines and sense amplifiers. This is not a subtle operation at the hardware level.
From software, you see addresses and bytes. From the hardware perspective:
Virtual Address
↓
Page Table
↓
Physical Address
↓
Memory Controller
↓
DRAM Bank and Row
↓
Row Activation / Sense Amplifiers
The gap between what software sees and what hardware does is where Rowhammer lives.
The Hammering Mechanism
DRAM cells are densely packed. When a wordline is asserted and a row is activated, the electrical disturbance is not perfectly contained. Neighboring rows can experience small amounts of interference.
In normal usage, this doesn't matter. A row is activated occasionally, and DRAM refresh operations periodically restore charge to cells before they drift too much.
But if an attacker repeatedly activates a row in a tight loop, hundreds of thousands of times per second, the cumulative electrical disturbance in neighboring rows can grow. The capacitors in those adjacent rows get disturbed more than the refresh mechanism expected. In some DRAM chips and configurations, this can cause a bit in a neighboring row to flip from its correct value to the opposite state.
Victim Row
─────────────────────────────────────
↑ electrical disturbance
─────────────────────────────────────
Hammer Row A Hammer Row B
█████████████ █████████████
activate activate
activate activate
activate activate
... ...
Double-sided hammering, where rows on both sides of the victim row are repeatedly activated, concentrates the disturbance from two directions. This can increase the chance of inducing a flip in a susceptible system compared to hammering one side.
Susceptibility varies. Not every DRAM module experiences this, and behavior depends on the DRAM design, manufacturing process, access pattern, timing, temperature, and what mitigations are present.
Why Software Isolation Doesn't Stop It
This is the counterintuitive part.
The operating system creates an abstraction: each process has a virtual address space, and the page table ensures that accesses to one process's memory don't reach another process's pages. When Process A tries to read Process B's memory, the CPU checks the page table and refuses.
Rowhammer doesn't ask the CPU to access another process's memory. It stays within its own legal pages.
Process A (attacker)
Legal pages
████████████████
↓
repeated activation
↓
Physical DRAM disturbance
↓
Nearby physical cells
↓
████████████████
Victim memory (different process or OS)
↓
possible bit flip
The CPU's page-table permission check is bypassed not because it was defeated, but because the attacker never triggered it. The hardware underneath the abstraction is doing something the abstraction wasn't designed to account for.
From a Bit Flip to a Security Consequence
A random bit flip in an unused region of memory is just data corruption. Annoying, not dangerous.
The security question is whether an attacker can cause a bit to flip in a location that matters: a page table entry, permission bits on a memory page, metadata used by the OS to track ownership, or values the program trusts as authoritative.
Physical disturbance
↓
Bit flip
↓
Security-sensitive location
↓
Corrupted metadata or permission structure
↓
Potential isolation violation
For this to go from bit flip to exploit, several things need to align: the flip has to happen in the right location, the attacker needs some ability to influence physical memory placement, the corrupted value has to be security-sensitive, and the system has to act on it before detecting the inconsistency.
This makes Rowhammer exploitation significantly harder than pointing it at a target and waiting. But researchers have demonstrated that, in certain configurations, this chain can be constructed.
Rowhammer vs. Software Memory Corruption
It's worth being precise about the distinction.
A buffer overflow is a software bug. The program writes past the end of a buffer because bounds checking failed or was absent.
A use-after-free is a software lifetime bug. The program accesses memory it no longer owns.
Rowhammer is neither. The attacker performs memory accesses that are within their permissions. No application bug is involved. The disturbance occurs in the physical DRAM subsystem, not in a software buffer.
Buffer overflow:
program writes outside intended bounds (software bug)
Use-after-free:
program accesses freed memory (software bug)
Rowhammer:
program performs legitimate accesses
→ hardware disturbance
→ bit flip in different physical location
This means traditional software mitigations like address-space layout randomization, stack canaries, or safe languages don't address the underlying phenomenon. The vulnerability exists at a layer below them.
Why Mitigations Are Difficult
Several mitigations exist, and each operates at a different layer.
Increased refresh rates. Refreshing DRAM cells more frequently reduces the window during which a cell can drift. This trades power and bandwidth for resilience.
Targeted Row Refresh (TRR). The memory controller or DRAM monitors row activation frequency. When a row crosses a threshold, neighboring rows are proactively refreshed. TRR implementations vary, and some have gaps under certain access patterns.
ECC memory. Error-correcting code memory can detect and correct certain bit errors. For single-bit errors, most ECC schemes can correct the flip transparently. But ECC doesn't prevent the flip from occurring, and multi-bit or unusual error patterns may fall outside what the scheme can correct.
OS-level strategies. Careful physical memory allocation can reduce the chance that attacker pages are physically adjacent to sensitive structures. This changes what a flip can reach but doesn't prevent the underlying disturbance.
No single mitigation addresses all configurations. Rowhammer is partly a hardware problem and partly an architectural one, and the mitigations reflect that.
The Deeper Lesson
Security boundaries in software depend on the layers underneath behaving as expected.
The operating system's isolation model assumes that one process cannot influence another's memory without going through software primitives that the OS controls. That assumption is correct at the software layer.
Rowhammer reveals that the physical implementation of memory can introduce a side channel that crosses that boundary without touching any of the software mechanisms guarding it.
This isn't a failure of the page table, the CPU, or the operating system. It's a reminder that software abstractions are built on physical systems, and those physical systems have their own properties.
The attacker can access Row A.
The victim's data is in Row B.
The attacker cannot write Row B.
But repeated activation of Row A
can disturb nearby DRAM cells.
If a bit in Row B flips,
software observes a state it never intentionally created.
Rowhammer doesn't break the rule that you can't write someone else's memory.
It attacks the hardware underneath the rule.
