Rowhammer

Executive Summary

Rowhammer is a hardware vulnerability in dynamic random-access memory (DRAM) chips, originally characterized by Yoongu Kim and colleagues at Carnegie Mellon University and Intel Labs in their 2014 ISCA paper "Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors." The phenomenon is straightforward in principle: repeatedly accessing a row of DRAM cells causes electrical disturbance in physically adjacent rows, which over enough activations causes individual bits in those neighboring rows to flip from 1 to 0 or vice versa. What began as an academic reliability finding became, within a year, a security vulnerability when Mark Seaborn and Thomas Dullien at Google Project Zero demonstrated user-level Rowhammer-based privilege escalation exploits on real systems.

Rowhammer matters because it is the first documented, widespread system security vulnerability rooted in a circuit-level hardware failure mechanism. It cannot be patched in software in any complete sense. Each subsequent generation of mitigation — pseudo-Target Row Refresh (pTRR) on DDR3, in-DRAM Target Row Refresh (TRR) on DDR4, refresh-rate adjustments, ECC memory — has been demonstrated to be partially or fully bypassable by new attack variants. The threshold number of activations required to induce a bit flip has dropped from approximately 140,000 on early DDR3 to fewer than 5,000 on LPDDR4 over the course of a decade, as DRAM cell density has continued to scale.

Operationally, Rowhammer reframed memory itself as a trust boundary that could be undermined from userspace. Subsequent research expanded the attack surface across virtually every modern memory technology: Rowhammer.js (browser-based, JavaScript), Drammer (Android root exploit), Flip Feng Shui (cross-VM attacks against cloud), Throwhammer/Nethammer (network-triggered), RAMBleed (read secrets, not just flip them), TRRespass and Blacksmith (DDR4 with TRR bypass), Half-Double (skipping a row), RowPress (long-row-open variant), and ZenHammer (DDR5 on AMD Zen). Defenders cannot reliably "patch" Rowhammer; they can only manage exposure, prefer hardware with stronger mitigations, and design systems that tolerate occasional bit corruption.

Why This Belongs in the Archive

Rowhammer belongs in the archive because it established a vulnerability category that previous defender frameworks had no place for: a circuit-level scaling issue, present at the silicon layer, exploitable from software, with no software-only fix.

It exposed systemic infrastructure dependency on the assumption that memory writes and reads are isolated to the addresses involved — an assumption that turned out to be approximately, but not completely, true.

It demonstrated supply-chain blast radius across virtually every device with modern DRAM: workstations, servers, smartphones, embedded systems, cloud infrastructure. The "affected vendor" list is essentially every DRAM manufacturer in the industry.

It produced a continuing research stream that is still active a decade later. Each new memory generation introduces new mitigations; each new generation of mitigations has been bypassed within a few years.

It informed later thinking about hardware-level trust assumptions, complemented Spectre and Meltdown in establishing that hardware fallibility is a permanent part of the threat model, and shaped how cloud providers think about cross-tenant isolation at the physical-memory layer.

Key Facts

Background

DRAM stores each bit of information in a tiny capacitor that holds or releases an electrical charge. Capacitors leak charge over time, so DRAM must be periodically "refreshed" — read out and written back — to preserve its contents. The standard JEDEC refresh interval is 64 milliseconds at room temperature; every cell in DRAM must be refreshed within that window or its contents may decay.

As DRAM cell sizes have shrunk from generation to generation (from DDR2 through DDR5, and from DDR3 through LPDDR5 on the mobile side), capacitors have become physically smaller and packed closer together. This scaling improves density and performance but introduces a parasitic effect: activating one row of DRAM can electrically disturb adjacent rows. The disturbance, repeated frequently enough within a single refresh window, can cause some cells in adjacent rows to lose enough charge that they flip from 1 to 0 (or, in some cell architectures, the reverse).

The 2014 ISCA paper by Kim et al. systematically characterized this phenomenon across DRAM modules from multiple vendors and established that the failure mode was reproducible, predictable, and present in commodity DRAM that had passed all standard manufacturer testing. The paper was framed as a reliability issue. The security implications followed quickly.

In March 2015, Mark Seaborn and Thomas Dullien at Google Project Zero published two working privilege-escalation exploits using Rowhammer. The first used Native Client's sandbox escape primitives; the second escalated to kernel privileges from an unprivileged userspace process on Linux. The transformation from "interesting hardware reliability issue" to "exploitable security vulnerability" was complete.

By 2026, Rowhammer has produced a continuing twelve-year research arc with no clear endpoint. Each new mitigation has eventually been bypassed; each new memory generation has introduced new variants. The threshold number of activations required to induce a bit flip — the "Rowhammer threshold" or TRH — has fallen approximately 30-fold over the decade, from around 140,000 on early DDR3 to under 5,000 on the most vulnerable LPDDR4 chips tested.

What Happened

Rowhammer is best understood as a research arc rather than a single incident. The principal milestones:

2014 (June): Kim et al., ISCA 2014. Original characterization. Demonstrated that 110 of 129 DRAM modules tested produced bit flips. Framed as a reliability issue.

2015 (March): Google Project Zero "Exploiting the DRAM rowhammer bug to gain kernel privileges." Mark Seaborn and Thomas Dullien published two working privilege-escalation exploits. The Rowhammer security era began.

2015–2016: Rowhammer.js. Daniel Gruss et al. demonstrated Rowhammer attacks executable from within a web browser using JavaScript. The implication was that visiting a malicious web page could potentially flip memory bits in the user's process — moving the attack from "local malicious code" to "remote, no-user-interaction" territory.

2016 (October): Drammer. Researchers at Vrije Universiteit Amsterdam (Veen, Frigo, Razavi, Bos, Giuffrida, Gruss, et al.) demonstrated reliable root privilege escalation on multiple Android smartphones using Rowhammer combined with deterministic memory massaging ("Flip Feng Shui"). CVE-2016-6728 was assigned. Google released a partial mitigation within a month.

2016: Flip Feng Shui. Razavi et al. demonstrated cross-VM attacks against cloud workloads, using memory deduplication to align attacker-controlled and victim-controlled memory pages and then triggering Rowhammer to flip specific bits in the victim's data.

2018 (May): Throwhammer / Nethammer. Two parallel research teams demonstrated that Rowhammer could be triggered remotely without code execution on the target — Throwhammer used RDMA, Nethammer used unprivileged network packet processing. The implications for cloud and high-speed networking environments were severe.

2019 (June): RAMBleed. Kwong et al. demonstrated that Rowhammer could be used to read memory rather than only flip bits, by inferring the value of victim cells from whether they did or did not flip. RAMBleed extended the threat model from integrity attacks to confidentiality attacks. Demonstrated extraction of an OpenSSH RSA key.

2020 (March): TRRespass. Frigo, Vannacci, Hassan, et al. demonstrated that the in-DRAM Target Row Refresh (TRR) mitigation deployed in DDR4 was vulnerable to "many-sided" Rowhammer patterns that used many aggressor rows simultaneously. Tested 42 DDR4 modules from Samsung, Micron, and Hynix; 13 were vulnerable to the new attack patterns. The "DDR4 is safe" narrative collapsed.

2021 (November): Blacksmith. ETH Zurich's COMSEC group introduced a fuzzing-based Rowhammer technique that produced effective attack patterns against all 40 modern DDR4 modules tested, including systems where prior TRR-aware techniques had failed. Demonstrated practical RSA-2048 key recovery against an SSH server.

2021: Half-Double. Google researchers demonstrated that bit flips could be induced in rows two steps away from the aggressor, not just immediately adjacent — a finding that further complicated the design of TRR-style mitigations.

2023 (June): RowPress. ETH Zurich researchers demonstrated a new variant that achieves bit flips by keeping rows open for extended periods rather than rapidly toggling them, requiring far fewer activations. Particularly concerning because performance-oriented memory controllers prefer keeping rows open.

2024 (March): ZenHammer. ETH Zurich demonstrated successful Rowhammer attacks against AMD Zen-based systems with both DDR4 and DDR5 memory, contradicting earlier suggestions that DDR5's improved refresh and on-die ECC made it inherently safe.

What made the response difficult, throughout the entire arc, was the structural fact that no software patch can fully eliminate Rowhammer. Mitigations have been incremental, often vendor-specific, and routinely bypassed within a few years of deployment.

Technical Overview

A DRAM chip is organized into banks, each bank into rows, each row into a sequence of cells. To read data from a cell, the memory controller "activates" the row, copying its contents into a row buffer, then reads the desired column. The activation creates a brief, intense electrical event along the row's wordline.

Capacitors in physically adjacent rows are not perfectly isolated from this electrical event. A small amount of charge leaks across the gap, slightly reducing the charge stored in adjacent cells. Normally, the standard 64ms refresh interval restores the cells before they decay enough to lose their stored value. But if an attacker activates the same row hundreds of thousands of times within a single refresh interval, the cumulative disturbance to adjacent rows can be enough to flip bits before the next refresh.

The original Kim et al. paper documented "single-sided" Rowhammer (one aggressor row) and "double-sided" Rowhammer (two aggressor rows on either side of a victim row, which is more effective). Subsequent research developed:

• Many-sided Rowhammer (TRRespass): Use many aggressor rows simultaneously to overwhelm in-DRAM TRR sampling.
• Non-uniform patterns (Blacksmith): Use varied, fuzzer-discovered access patterns that defeat TRR's sampling logic.
• Half-Double: Hammer rows two steps away, exploiting a leakage path that earlier mitigations did not anticipate.
• RowPress: Keep rows open for extended periods rather than rapidly toggling, exploiting a different physical mechanism (charge leakage during the row-open state).

For exploitation, an attacker needs to:

1. Locate exploitable bit flips. Profile the target system to find DRAM rows where bit flips can be induced reliably.
2. Massage memory layout. Arrange for a victim's sensitive data (page table entry, cryptographic key, sandbox security flag) to land in a victim row that the attacker can hammer.
3. Trigger the flip. Hammer the aggressor rows enough to flip the targeted bit.
4. Use the flip. Convert the bit flip into a meaningful security primitive — typically privilege escalation via PTE corruption, sandbox escape, or key recovery.

Memory massaging is non-trivial and has been a major focus of Rowhammer research. Techniques include filling memory with target-shaped data, exploiting kernel allocators' deterministic placement behavior, and using memory deduplication (in cloud / VM environments) to merge attacker and victim pages.

The bypassing of in-DRAM TRR is the most operationally important technical development of the post-2020 period. TRR was advertised by DRAM vendors as a "silver bullet" mitigation. TRRespass demonstrated that TRR is in fact a family of vendor-specific implementations, all using sampling-based detection of aggressor rows, and all defeatable by patterns that overwhelm the sampler. Blacksmith's fuzzer-discovered patterns defeated every DDR4 module the researchers tested.

Affected Vendors and Devices

Unlike Ripple20 or VPNFilter, Rowhammer's affected list is best understood as "essentially every system with modern DRAM, to varying degrees." The more useful framing is which DRAM generations and which CPU/system contexts have been tested and found vulnerable.

DRAM Manufacturers

The three major DRAM vendors — Samsung, Micron, and SK Hynix — collectively manufacture the vast majority of DDR3, DDR4, LPDDR3, LPDDR4, and DDR5 memory in the industry. All three have had products characterized as Rowhammer-vulnerable in academic research. The TRRespass paper specifically tested modules from all three vendors and found vulnerable products in each.

DRAM Generations

Affected System Categories

Because Rowhammer affects DRAM rather than CPU, the system list spans:

• Servers and workstations: All x86 (Intel and AMD), ARM-based servers (Ampere, Graviton, etc.), IBM POWER and z/Architecture systems with vulnerable DRAM.
• Cloud infrastructure: All major cloud providers run on DRAM that is, or has been, vulnerable to some Rowhammer variant. Cross-tenant attacks (Flip Feng Shui, Throwhammer, RAMBleed) explicitly targeted this scenario.
• Smartphones and tablets: Drammer demonstrated reliable exploitation on multiple Android handsets in 2016. iOS devices use similar LPDDR4/5 memory and are likely vulnerable to the underlying mechanism, though Apple-specific public exploitation reports are less common.
• Embedded and IoT devices: Any device with modern DDR or LPDDR memory shares the underlying vulnerability. Practical exploitation depends on the attack surface above the memory layer.
• Network appliances and storage controllers: Same situation as embedded devices.

CPU Vendor Context

Rowhammer is a DRAM phenomenon, but CPU and memory-controller behavior shapes exploitability. The major CPU vendors have been involved at the mitigation layer:

• Intel systems with DDR4 implement memory-controller-level mitigations including pTRR and refresh-rate adjustments; ECC support on server platforms provides additional resistance.
• AMD systems were demonstrated vulnerable in ZenHammer (2024) for both DDR4 and DDR5 configurations.
• ARM-based mobile platforms (Qualcomm, Samsung Exynos, Apple A-series, MediaTek) are exposed via the LPDDR4/5 memory they pair with.
• IBM POWER and z/Architecture systems use ECC memory by default, which raises the bar for exploitation but does not eliminate the underlying vulnerability.

The practical takeaway: any system with DRAM manufactured in the last fifteen years should be considered vulnerable to some Rowhammer variant in the absence of specific evidence to the contrary.

Impact

Operational Impact

Rowhammer's operational impact is unusual because it manifests primarily through research disclosures rather than incidents. The vulnerability has been continuously demonstrated since 2014, but in-the-wild exploitation has been rare — or rather, rarely confirmed. The cost has been borne primarily by:

• DRAM manufacturers, who have absorbed the cost of designing, implementing, and continuously revising in-DRAM mitigations across generations.
• OS and hypervisor vendors, who have implemented memory-layout hardening (e.g., the kernel-level mitigations Linux added in response to Drammer; cloud providers' work on memory deduplication policies).
• Cloud providers, who manage the cross-tenant exposure through memory-allocation policies, ECC requirements, and host-level monitoring.

For most enterprise defenders, the operational cost has been small — primarily, an awareness-and-procurement adjustment.

Security Impact

The security impact, however, is substantial in principle:

• Privilege escalation: User-level processes can become root via PTE corruption (Drammer, original Project Zero exploits).
• Sandbox escape: JavaScript-based attacks can escape browser sandboxes (Rowhammer.js).
• Cross-VM attacks: Cloud tenants can attack other tenants on the same host via memory deduplication (Flip Feng Shui).
• Remote attacks: RDMA and high-throughput network paths can trigger bit flips without local code execution (Throwhammer, Nethammer).
• Confidentiality breach: RAMBleed extracts secrets, including cryptographic keys (RSA-2048 demonstration in Blacksmith).
• Integrity corruption: Any data structure with security significance — capability tables, access control lists, kernel structures — is potentially flippable.

The combination of these primitives means Rowhammer is, in principle, a complete-stack threat: from local userspace through kernel through hypervisor through cloud tenant boundary.

Business / Continuity Impact

Direct business impact has been limited because the in-the-wild exploitation rate has been low. The strategic impact has been larger: cloud architecture, hardware procurement, and trust modeling for high-sensitivity workloads have all been adjusted in response.

For high-assurance workloads (cryptographic operations, multi-tenant separation, regulated environments), Rowhammer creates a permanent residual risk that must be managed through hardware selection (ECC memory, server-grade DRAM with stronger mitigations), workload placement (avoiding co-location with untrusted workloads), and software hardening (memory layout randomization, defensive coding for security-sensitive structures).

What This Was Not

Rowhammer was not malware. It is a hardware vulnerability class, exploited by software but not in itself an attack tool.

It was not fully fixable in software. Software-level mitigations (Linux kernel hardening, cloud memory-deduplication policy changes, browser-side mitigations against Rowhammer.js) addressed specific exploitation paths, but the underlying physical phenomenon remains in the silicon.

It was not solved by DDR4. The "DDR4 is Rowhammer-resistant" narrative — built around in-DRAM TRR — was definitively disproven by TRRespass (2020) and Blacksmith (2021).

It was not solved by DDR5. The "DDR5 is Rowhammer-resistant" narrative was challenged by ZenHammer (2024). Improved refresh and on-die ECC raise the exploitation bar but do not eliminate the vulnerability.

It is not, currently, primarily a campaign-style threat. As of the 2026 archive date, in-the-wild Rowhammer exploitation by named threat actors has not been widely confirmed. The threat is structural and persistent rather than active and visible.

Evidence and Source Notes

Evidence is organized by proximity to the event. Academic primary research is treated as highest-confidence for the technical phenomenon and exploitation feasibility. JEDEC standards documents are authoritative for DRAM specification details. Industry guidance is used to support defender framing.

Remediation

Rowhammer's remediation guidance is structurally different from typical vulnerability response. There is no single patch, no version-bump, no signature. The defender's job is to manage exposure across procurement, platform, and architecture decisions.

Immediate Actions: 0–24 Hours

For most organizations, there are no useful 0–24 hour Rowhammer-specific actions. The vulnerability is structural, not active. The realistic immediate-window guidance is:

• Validate that current OS and browser updates are applied. Most browsers have implemented mitigations against Rowhammer.js-style attacks (reduced timer precision, restricted high-resolution timing primitives).
• Validate that cloud workloads are on instance types that use ECC memory. Confirm with the cloud provider that memory-deduplication policies are appropriate for sensitive workloads.

Short-Term Actions: 1–7 Days

• Inventory systems by memory type: ECC vs. non-ECC, DDR3/4/5 generation, server-grade vs. consumer-grade DRAM.
• Identify high-sensitivity workloads (cryptographic operations, multi-tenant separation, regulated data) and assess whether they are running on memory with appropriate mitigations.
• Review browser and runtime configurations to ensure standard Rowhammer.js mitigations (timer precision restrictions, sandbox layout hardening) are in effect.

Medium-Term Actions: 1–4 Weeks

• Update procurement standards: require ECC memory for any workload with confidentiality or integrity requirements above standard. Prefer server-class DRAM with documented Rowhammer mitigations from DRAM vendors.
• Review cloud workload placement: for high-sensitivity workloads, prefer dedicated tenancy or instance types that provide stronger memory isolation guarantees.
• Update threat models for hardware-rooted vulnerabilities. Rowhammer-class threats should be a recognized category, even if mitigation is mostly procurement-driven.

Long-Term Actions: 1–6 Months

• Treat memory subsystem characteristics as part of the security posture for high-assurance workloads. Consider DRAM generation, ECC support, in-DRAM mitigation status, and refresh behavior as procurement criteria.
• For environments running cryptographic services, consider hardware security modules (HSMs) or trusted execution environments (TEEs) for key operations rather than relying on DRAM-resident keys.
• Track DRAM vendor and JEDEC mitigation roadmaps. The state of art in Rowhammer mitigation continues to evolve; stay current on which generations and which products are believed to be more resistant.
• Include Rowhammer-class threats in tabletop exercises for high-assurance environments. Most existing IR plans do not contemplate hardware-rooted memory corruption as a scenario.
• For embedded and IoT product development, design defensive memory layouts: avoid placing security-critical data structures in deterministic memory locations, use ECC where the BOM allows, and consider redundancy for high-integrity values.

Timeline

Indicators, Artifacts, or Detection Notes

Indicators

Detection Logic

Detection of Rowhammer exploitation is difficult and not well-developed in commercial tooling. The fundamental problem is that Rowhammer access patterns can closely resemble legitimate workloads (especially those with poor cache locality), and the bit flip itself produces no obvious signal until something built on the corrupted bit fails.

Practical detection signals that have been studied:

• ECC-corrected error rate spikes: Sudden increases in correctable ECC events on specific DIMMs may indicate Rowhammer-class activity. False-positive prone.
• Cache miss rate signatures: Rowhammer exploits typically use clflush or cache-eviction techniques to ensure DRAM accesses bypass cache; this produces unusually high LLC miss rates that are detectable in performance counter telemetry.
• Hardware performance counter monitoring: Tools like NumChecker and others have proposed using hardware performance counters to detect Rowhammer-like patterns in real time. Effective in research; uncommon in production.
• Memory deduplication observation: In cloud / hypervisor contexts, monitoring for patterns consistent with Flip Feng Shui-style memory massaging.

For most defender environments, "detection" effectively means tracking the research literature and applying mitigation guidance, not real-time alerting.

Tooling

• rowhammer-test (Mark Seaborn): Original Project Zero proof-of-concept.
• TRRespass tool: Released by VUSec for testing DDR4 modules.
• Blacksmith fuzzer: Released by ETH Zurich COMSEC; can characterize a DDR4 module's TRR behavior.
• Drammer test app (Android): Released to allow users to test their own devices.
• JEDEC documents: JEP 300-1, JEP 301-1 (Half-Double mitigation guidance).

Any scripts or tools referenced here are preserved for historical context unless explicitly marked as current.

Infrastructure Defense Lessons

1. What defenders should remember

Hardware reliability mechanisms can become security vulnerabilities. A class of physical effect that DRAM engineers had been managing as a reliability concern turned out, when analyzed under an adversarial lens, to be an exploitable security primitive. The same pattern has appeared elsewhere — Spectre and Meltdown converted speculative execution from a performance feature into an information disclosure surface. Expect more.

2. What organizations underestimated

Defenders underestimated the durability of the underlying physical phenomenon. The 2015 industry response framed Rowhammer as "interesting research" with the expectation that newer DRAM generations would resolve it. A decade later, every generation that was supposed to solve it has been demonstrated vulnerable. The threshold has been falling, not rising.

The other underestimated factor was the breadth of the exploitation surface. The original 2014 paper anticipated local exploitation. Subsequent research demonstrated browser-based, remote network-based, and cross-VM exploitation, expanding the threat model substantially beyond what early respondents had anticipated.

3. What held up well

Server-class infrastructure with ECC memory has held up reasonably well. While ECC does not make Rowhammer impossible, it raises the bar substantially — the attacker must induce uncorrectable multi-bit flips, not merely single-bit flips. For many workloads, this is the difference between practical and impractical exploitation.

Cloud providers' progressive tightening of memory-deduplication policies reduced the cross-VM attack surface in production environments.

The browser security ecosystem responded effectively to Rowhammer.js. Reduced-precision timing primitives, site isolation, and process-per-origin architecture have collectively raised the bar against browser-based variants.

4. What failed or became fragile

In-DRAM TRR was over-promised and under-delivered. The "TRR makes DDR4 safe" narrative survived in industry messaging from roughly 2016 to 2020, despite TRR's vendor-by-vendor implementation differences and the lack of public documentation of its actual behavior. TRRespass and Blacksmith demonstrated that a security claim built on a proprietary, undocumented sampling-based mitigation should be treated with skepticism.

Defender threat models that treated DRAM as a fundamentally trusted layer have aged poorly. Memory is now part of the threat surface, even if the practical exploitation rate remains low.

5. What this changed in practice

Rowhammer changed how defenders and architects think about memory. Before 2014, memory was treated as a layer below the security model — assumed to be reliable, isolated, and trustworthy. After Rowhammer (and in conjunction with Spectre and Meltdown), memory and the platform layer below it became part of the threat surface to be tracked.

Procurement language evolved to specify ECC requirements, memory generation, and (in some contexts) Rowhammer-mitigation expectations. Cloud providers added memory-architecture details to their security documentation. Sensitive workload placement became a more nuanced problem than just "is the host patched?"

Most importantly, Rowhammer entrenched the principle that defenders should expect more circuit-level security findings. The hardware below the OS is fallible in ways that may not be discovered for years. The defensive posture is to assume hardware fallibility, prefer hardware with documented and tested mitigations, and design systems that tolerate or detect occasional integrity failures at the memory layer.

Key Takeaways

• Rowhammer is the canonical example of a circuit-level hardware failure mechanism becoming a security vulnerability.
• No software-only fix exists; mitigations are partial, vendor-specific, and routinely bypassed by new variants.
• Each DRAM generation that was supposed to solve Rowhammer has been demonstrated vulnerable, with the activation threshold falling over time.
• The exploitation surface has expanded from local privilege escalation to browser-based, network-triggered, cross-VM, and confidentiality attacks.
• ECC memory raises the exploitation bar substantially but does not eliminate the underlying vulnerability.
• High-assurance workloads should be placed on hardware with appropriate memory mitigations, with ECC at minimum.
• Memory subsystem characteristics belong in procurement and architecture decisions for sensitive environments.
• Expect more hardware-rooted vulnerability classes; Rowhammer is the pattern, not the exception.

References

1. Kim, Y., Daly, R., Kim, J., Fallin, C., Lee, J. H., Lee, D., Wilkerson, C., Lai, K., Mutlu, O. — "Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors." ISCA 2014.
2. Seaborn, M., & Dullien, T. — "Exploiting the DRAM rowhammer bug to gain kernel privileges." Google Project Zero, March 2015.
3. Gruss, D., Maurice, C., Mangard, S. — "Rowhammer.js: A Remote Software-Induced Fault Attack in JavaScript." DIMVA 2016.
4. van der Veen, V., Fratantonio, Y., Lindorfer, M., Gruss, D., Maurice, C., Vigna, G., Bos, H., Razavi, K., Giuffrida, C. — "Drammer: Deterministic Rowhammer Attacks on Mobile Platforms." CCS 2016.
5. Razavi, K., Gras, B., Bosman, E., Preneel, B., Giuffrida, C., Bos, H. — "Flip Feng Shui: Hammering a Needle in the Software Stack." USENIX Security 2016.
6. Tatar, A., Konoth, R. K., Athanasopoulos, E., Giuffrida, C., Bos, H., Razavi, K. — "Throwhammer: Rowhammer Attacks over the Network and Defenses." USENIX ATC 2018.
7. Lipp, M., et al. — "Nethammer: Inducing Rowhammer Faults through Network Requests." 2018.
8. Kwong, A., Genkin, D., Gruss, D., Yarom, Y. — "RAMBleed: Reading Bits in Memory Without Accessing Them." IEEE S&P 2020.
9. Frigo, P., Vannacci, E., Hassan, H., van der Veen, V., Mutlu, O., Giuffrida, C., Bos, H., Razavi, K. — "TRRespass: Exploiting the Many Sides of Target Row Refresh." IEEE S&P 2020.
10. Jattke, P., van der Veen, V., Frigo, P., Gunter, S., Razavi, K. — "Blacksmith: Scalable Rowhammering in the Frequency Domain." IEEE S&P 2022.
11. Kogler, A., et al. — "Half-Double: Hammering From the Next Row Over." USENIX Security 2022.
12. Luo, H., et al. — "RowPress: Amplifying Read Disturbance in Modern DRAM Chips." ISCA 2023.
13. Jattke, P., et al. — "ZenHammer: Rowhammer Attacks on AMD Zen-based Platforms." 2024.
14. Mutlu, O., & Kim, J. S. — "RowHammer: A Retrospective." IEEE Transactions on CAD of Integrated Circuits and Systems, 2019.
15. JEDEC — JEP 300-1 and JEP 301-1 (DRAM and system-level mitigation techniques for Half-Double).
16. Red Hat — "DRAM-Related Faults" customer portal article.