HyperHammer: Breaking Free from KVM-Enforced Isolation

Wei Chen, Zhi Zhang, Xin Zhang, Qingni Shen, Yuval Yarom, Daniel Genkin and 2 others

Rowhammer is a hardware flaw where hammering one region of memory flips bits in a neighboring region the attacker was never given access to, and in a cloud it threatens the promise that one customer's virtual machine cannot touch another's — but published attacks only ever reached other guest machines, never the all-powerful hypervisor beneath them, and even those relied on a feature since switched off for safety; this work from a group including Peking University, Western Australia, and Georgia Tech presents HyperHammer, a Rowhammer attack that breaks the isolation the KVM hypervisor enforces and compromises the hypervisor itself in a modern virtualized environment.

The argument in one glance

Problem

Cloud isolation is promised in software but sits on physical memory

In the cloud, many customers share one machine, each inside a virtual machine that the hypervisor keeps isolated from the others and from itself. That isolation is enforced in software and hardware, but it ultimately assumes the physical memory faithfully holds each value. A hardware flaw that corrupts memory can undermine the whole promise.
What people did

Exploit Rowhammer to corrupt memory across the boundary

Rowhammer is a known memory defect: hammering one row of cells can flip bits in a neighboring row the attacker cannot address. Prior work used it in clouds to corrupt memory across virtual machine boundaries.
Why it fell short

Prior attacks reached only other guests, and no longer apply

Published Rowhammer attacks in virtualized clouds compromised only co-resident guest virtual machines, never the powerful hypervisor beneath them. Worse, they depended on a system feature that has since been disabled for security, so those attacks no longer work in a contemporary environment. Whether the hypervisor could still be broken was left open.
This paper's idea

Break the KVM-enforced boundary to the hypervisor

HyperHammer is a Rowhammer attack that breaks the isolation the KVM hypervisor enforces, compromising the hypervisor itself — not merely a co-resident guest — in a modern virtualized environment, without relying on the feature that earlier attacks needed and that has since been turned off. It shows the cloud's central isolation promise remains at risk from a hardware flaw today.

Why this problem is worth solving

The cloud’s core guarantee is isolation, and it depends on hardware behaving.

Public clouds pack many customers onto shared physical machines to use them efficiently. To make this safe, each customer runs inside a virtual machine, an isolated software environment that behaves like a private computer. A hypervisor — the supervising software that creates and manages the virtual machines — together with hardware-assisted virtualization features in the processor, keeps each guest confined: a guest cannot read or write another guest’s memory, and cannot reach into the hypervisor that stands above them all. This isolation is the security promise the whole cloud rests on, and it enables the flexibility customers rely on, such as moving a running machine to different hardware or provisioning resources on demand. In the common cloud model here, the hypervisor is the widely used KVM, the virtualization layer built into Linux. The crucial point is that all of this isolation is enforced in software and processor logic that assume one thing about the layer beneath them: that physical memory faithfully stores whatever is written to it. Every permission check, every mapping that separates one guest from another, is only as trustworthy as the memory holding those values. If the physical memory can be made to change values on its own, the isolation built on top of it can be subverted from below — which is exactly the opening Rowhammer provides.

Rowhammer is that opening, and closing it has been an arms race.

Rowhammer is a reliability defect in modern memory chips. To pack more capacity, memory cells are placed extremely close together, and the electrical charge that stores a bit in one cell can leak and disturb its neighbors. Researchers found that by repeatedly and rapidly accessing one row of cells — hammering it — an attacker can cause bits to flip in an adjacent row, even though the attacker has no permission to access that row. The attacker changes the contents of memory it was never allowed to touch. In a single computer this is dangerous; in a shared cloud it is systemic, because a guest’s memory sits physically next to memory belonging to other tenants and to the hypervisor. A well-placed bit flip can therefore cross a trust boundary — corrupting another customer’s data, or altering a hypervisor structure to the attacker’s advantage. Because the threat is so serious, defenders have responded over the years, and one line of defense was to disable a system feature that earlier cloud Rowhammer attacks depended on to succeed. That is why the paper notes those published attacks are no longer applicable in a contemporary virtualized environment: the enabling component was taken away. The open and worrying question this work addresses is whether, even so, a Rowhammer attack can still break the hypervisor’s isolation on a modern cloud machine.

What people did before, and where it broke

Rowhammer against co-resident guest virtual machines. Use bit flips to corrupt memory belonging to another tenant sharing the same physical machine. Where it broke. These attacks reached only sibling guests, not the hypervisor, so the most powerful layer — the one whose compromise would give control over all guests — stayed out of reach.
Rely on a since-disabled enabling feature. The published cloud attacks depended on a particular system feature to line up the attacker’s and victim’s memory. Where it broke. For security reasons that feature was disabled, and without it the attacks no longer function in a contemporary environment.
Assume mitigations ended the threat. With those attacks neutralized, one might assume Rowhammer no longer breaks cloud isolation. Where it broke. Rowhammer itself was never fixed at the hardware level, so the question of whether a new attack could still reach the hypervisor remained genuinely open.
The gap. No published attack had shown that a Rowhammer adversary could still break the isolation the KVM hypervisor enforces, and compromise the hypervisor itself, in today’s virtualized cloud without the disabled feature. Demonstrating exactly that is what HyperHammer reports.

How HyperHammer fits the picture

From a hardware flaw to a broken hypervisor boundary

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

A physical property of the hardware defeats a logical guarantee. The isolation the hypervisor promises is a logical construction — permission bits, memory mappings, access checks — but it lives in physical memory cells, and Rowhammer shows those cells are not perfectly reliable. HyperHammer’s premise is that a purely physical disturbance, hammering rows of memory, can reach up and change the logical structures that enforce separation between a guest and the hypervisor. Turning an overlooked physical characteristic of the hardware into a way to violate a guarantee the software believed it held is the same surprise the analog-memory covert-storage work covered elsewhere on this site turns to a different end, using the tiny, unintended physical preferences of memory cells to carry information the logical system never meant to expose.

Cross the boundary that was supposed to be uncrossable. The value of an attack is measured by which wall it breaches, and HyperHammer aims at the strongest one in the stack: not another tenant, but the hypervisor that governs every tenant. Reaching it means an unprivileged party inside a confined environment defeats the very mechanism designed to keep it confined. Escaping the boundary an isolation mechanism was built to enforce, from a position that was assumed to be safely contained, is the same move the scheduler-abuse work covered elsewhere on this site makes on a different boundary, letting an unprivileged actor defeat the separation a system’s scheduling rules were meant to guarantee.

Show a mitigated threat is not a solved one. Defenders responded to earlier cloud Rowhammer by disabling a feature those attacks relied on, and it was tempting to treat the threat as handled. HyperHammer’s contribution is to demonstrate that the underlying hardware flaw was never removed, so a new attack can still reach the hypervisor without that feature — the mitigation narrowed one path but did not close the vulnerability. Showing that a hardware weakness persists and can be re-exploited despite a deployed mitigation is the same lesson the pre-silicon speculation-fuzzing work covered elsewhere on this site drives home from the defender’s side, that such flaws must be found and fixed at their hardware root because working around their symptoms leaves the door open.

The general Rowhammer attack, applied to this boundary

How a Rowhammer attack is mounted (standard background)

These are the classic phases of a Rowhammer attack in general; HyperHammer's specific novel steps are beyond the abstract this page is based on.

Step 1 of 5

Template the memory for flippable bits

The attacker hammers many rows of memory and records which physical bit positions reliably flip. This builds a map, or template, of the vulnerable cells on this particular machine.

Not every cell flips; the attacker needs to know where the exploitable ones are.

Why it works

Software isolation rests on hardware integrity. Because the hypervisor enforces separation with checks and mappings that live in memory → a hardware effect that changes memory the attacker cannot address → undermines the isolation from beneath the software that assumes memory is faithful.
Dense memory leaks between neighbors. Because packing cells ever closer lets a hammered row disturb the charge in the row beside it → repeatedly accessing one row can flip bits in an adjacent one → so an attacker limited to its own rows can still alter a neighbor’s.
The cloud multiplies the stakes. Because many tenants share one physical machine and its memory → a flip in the wrong place crosses a trust boundary between customers or into the hypervisor → so Rowhammer is a systemic threat to cloud isolation, not a local nuisance.
Prior attacks stopped short of the hypervisor. Because published cloud Rowhammer reached only co-resident guests and needed a feature since disabled → those attacks never threatened the hypervisor and no longer apply → so whether the hypervisor could be broken today stayed open.
HyperHammer answers that it can. Because HyperHammer breaks the KVM-enforced boundary in a contemporary environment → it compromises the hypervisor rather than merely another guest → so the cloud’s central isolation promise is shown to be at risk now, not only in the past.

What it costs (trade-offs and scope)

It is an attack, and a full defense is separate. HyperHammer demonstrates a weakness rather than fixing one. Truly closing it requires hardware-level Rowhammer defenses; disabling individual enabling features, as before, narrows paths but does not remove the underlying flaw.
It targets a specific setup. The result concerns the KVM hypervisor and a particular virtualized configuration. Its applicability to other hypervisors, memory types with stronger in-hardware Rowhammer protection, or different provisioning setups is not something this summary can characterize.
Rowhammer attacks are demanding to mount. In general, such attacks require finding reliable bit flips on the target hardware and steering victim data into vulnerable physical locations, which is delicate and machine-specific. The precise requirements and reliability of HyperHammer are part of the full paper, not this abstract.
Responsible-disclosure norms apply. Attacks at top security-oriented venues are normally disclosed to affected vendors before publication so mitigations can be prepared; the specifics of disclosure for this work are in the paper.
The significance is qualitative here. This explainer conveys what boundary HyperHammer breaks and why that matters, but not quantitative results (success rates, timing, or exact conditions), because those were not available.
This page is written from the abstract. The full text was not accessible when this explainer was prepared, so the specific attack mechanism and all evaluation details are not reproduced; the mechanism above is generic Rowhammer background, clearly labeled.

The evaluation

Rowhammer against cloud isolation, before and with HyperHammer

Property	Prior cloud Rowhammer	After the mitigation
Boundary crossed		None, attack neutralized
Compromises the hypervisor		No
Works in a contemporary environment		Not applicable
Underlying hardware flaw	Present
What this page reports	Background	Background

How HyperHammer differs from prior cloud Rowhammer attacks, as characterized by the paper's abstract. Earlier virtualized Rowhammer attacks crossed only the boundary between co-resident guest virtual machines, never reaching the hypervisor, and they relied on a system feature that has since been disabled for security, so they no longer function on a contemporary cloud machine. Because the underlying Rowhammer hardware flaw was never removed, the question remained whether the hypervisor could still be broken. HyperHammer answers yes: it breaks the isolation the KVM hypervisor enforces and compromises the hypervisor itself in a modern virtualized environment, without the disabled feature. This table conveys the significance stated in the abstract; the specific attack technique and quantitative evaluation are in the full paper, which was not available for this explainer.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is written from the paper’s abstract, because the full text was not available when it was prepared, and the abstract itself states the problem and significance while stopping short of the attack’s details. So this page explains the setting and the stakes, and treats the Rowhammer mechanism only at the level of standard, widely-known background, clearly labeled as generic rather than specific to this work. The message that is clear and important is the security lesson. Cloud isolation is a promise made in software and processor logic, but it stands on physical memory, and Rowhammer — a decade-old hardware flaw where hammering one row of memory flips bits in a neighbor — can reach beneath that promise. Earlier cloud Rowhammer attacks were limited: they compromised only co-resident guest virtual machines, not the hypervisor, and they leaned on a feature that defenders have since disabled, so they no longer apply. HyperHammer’s reported contribution is to show that this mitigation did not end the threat, by breaking the isolation KVM enforces and compromising the hypervisor itself in a contemporary environment. Treat the specifics — how the attack is carried out, its success rate, and its exact conditions — as beyond what this summary can responsibly claim. The durable takeaway is that a hardware vulnerability persists until it is fixed in hardware, and that disabling the features a known attack used narrows the path without closing the underlying hole, so defenders must assume such flaws can be re-exploited.

Background

Why hardware flaws keep breaking software promises

It helps to place HyperHammer in a wider pattern that runs through systems security: the guarantees software makes are only as strong as the hardware they run on, and physical effects the software never modeled can quietly break them. The leaky-instruction defense work covered elsewhere on this site sits on the defensive side of the same divide, tracking down places where the hardware’s data-dependent behavior betrays a secret the software believed was protected, and neutralizing exactly those. Rowhammer is the aggressive counterpart: a physical disturbance in the memory chips reaches up to corrupt the logical structures that enforce isolation, so a promise the hypervisor makes in software is violated from below. The recurring lesson is that the boundary between the logical and the physical is where many of the hardest security problems live. Permission checks, memory mappings, and isolation guarantees are abstractions, and abstractions leak when the hardware beneath them does not behave the way the abstraction assumes. As machines grow denser and more shared, that gap widens, and the work of security increasingly means reasoning about how the physical substrate can be pushed to violate the logical rules — and building defenses, at the hardware level, that make the substrate trustworthy again.

If you remember only three things

1. Cloud computing promises that many tenants can share one physical machine while each stays isolated inside a virtual machine, separated from the others and from the hypervisor that manages them. That isolation is enforced in software and processor logic, but it ultimately assumes the physical memory faithfully holds its values. Rowhammer breaks that assumption: because dense memory cells disturb their neighbors, hammering one row can flip bits in an adjacent row the attacker has no permission to access, letting an attacker alter memory it was never allowed to touch — a systemic danger in a shared cloud where a guest's memory sits next to other tenants' and the hypervisor's.
2. Despite Rowhammer being known for over a decade, published attacks in virtualized clouds were limited: they compromised only co-resident guest virtual machines, never the more powerful hypervisor, and they depended on a system feature that has since been disabled for security, so they no longer work in a contemporary environment. HyperHammer reports breaking this stalemate. It is a Rowhammer attack that breaks the isolation the KVM hypervisor enforces and compromises the hypervisor itself, in a modern virtualized environment, without the disabled feature — showing that mitigating one enabling feature did not remove the underlying hardware flaw.
3. The durable lesson is that a hardware vulnerability persists until fixed in hardware, and disabling the features a known attack used narrows the path without closing the hole, so defenders must assume such flaws can be re-exploited against even the strongest software boundaries. Note: this explainer is written from the paper's abstract, which describes the problem and significance but not the attack details; the specific mechanism, success rates, and exact conditions are in the full paper, which was not available, and the Rowhammer mechanism described here is standard background, not this work's specific technique.

Check yourself

Check your understanding

1. What is Rowhammer, and why is it dangerous in a shared cloud?
2. Why were prior cloud Rowhammer attacks said to no longer apply, and what does HyperHammer show?
3. Why does the paper describe compromising the hypervisor as more significant than compromising a co-resident guest?
4. What is the broad security lesson this work illustrates about mitigations?

Sources

The paper is “HyperHammer: Breaking Free from KVM-Enforced Isolation” by Wei Chen, Zhi Zhang, Xin Zhang, Qingni Shen, Yuval Yarom, Daniel Genkin, Chen Yan, and Zhe Wang, published at ASPLOS 2025, DOI 10.1145/3676641.3716002. The authors are affiliated with institutions including Peking University, the University of Western Australia, Ruhr University Bochum, the Georgia Institute of Technology, and the Institute of Computing Technology of the Chinese Academy of Sciences. A public artifact accompanying the paper is hosted at github.com/harlanwei/hyperhammer-asplos2025.

This explainer is written from the paper’s abstract, because the full text was not available at the time of writing: the publisher’s version was behind automated-access protection, the paper’s open-access status was closed, and no preprint was available; only the abstract and the artifact’s README could be consulted. The problem and significance described here — the cloud isolation promise enforced by hardware-assisted virtualization and the KVM hypervisor, the Rowhammer hardware flaw, the limitation of prior virtualized Rowhammer attacks to co-resident guest virtual machines, the disabling of a feature those attacks relied on, and HyperHammer’s reported result of breaking the KVM-enforced boundary to compromise the hypervisor in a contemporary environment — come directly from the abstract. The abstract as published stops at the motivation and does not detail the attack technique or evaluation, so those are not reproduced here. The description of how a Rowhammer attack is mounted in general (templating flippable bits, placing victim data adjacent to them, hammering to trigger a flip, and exploiting the corrupted value), and the background on virtualization and hypervisor isolation, are standard, widely-known material provided to make the abstract’s claims understandable, and are not specific claims of this paper. The specific mechanism, success rates, and exact conditions of HyperHammer are in the full paper, which was not available.