02 — Memory Corruption Disasters

Technical Overview

Memory corruption vulnerabilities represent the single largest class of critical security bugs in systems software. When memory is corrupted — whether by reading too far, writing to freed regions, or exploiting hardware-level properties — the consequences range from privilege escalation to complete data exposure. This document examines five landmark memory corruption events that permanently altered how the industry builds, audits, and deploys software. Each involves a distinct corruption mechanism, and together they illustrate why eliminating memory unsafety at the language level is such a high-priority goal.

Prerequisites

Virtual memory and page tables (user space vs kernel space)
Stack vs heap memory layout
Copy-on-write (COW) semantics in fork()
TLS (Transport Layer Security) protocol internals
Linux kernel privilege model (ring 0 vs ring 3)
DRAM architecture (rows, banks, refresh cycles)
Linux cgroups v1/v2 internals

Historical Context

Memory corruption as a security vector dates to the 1988 Morris Worm (buffer overflow in fingerd). For the next 30 years, the industry deployed mitigations in layers: stack canaries (GCC SSP, 1998), non-executable stacks (NX bit, 2004), ASLR (Linux 2.6.12, 2005), RELRO, PIE. Each mitigation raised the exploitation bar but did not eliminate the underlying bug class. The events in this document show that even with all mitigations deployed, memory corruption continues to produce catastrophic outcomes — and that hardware-level attacks (Rowhammer) circumvent software-only defenses entirely.

Case Study 1: Dirty COW — CVE-2016-5195

Technical Root Cause

Dirty COW (Copy-On-Write) is a race condition in the Linux kernel's memory management subsystem that was present for nine years (Linux 2.6.22, released June 2007, through the patch in October 2016). It allowed any unprivileged user to write to any read-only memory-mapped file, including /etc/passwd, setuid binaries, and kernel memory-mapped files.

The vulnerability is in mm/memory.c, specifically in the interaction between get_user_pages() and the COW mechanism.

Normal COW semantics:
  Process A maps a read-only file with mmap(MAP_PRIVATE)
  Process A writes to the mapping
  Kernel: COW fault → allocate new private page → copy from file → write to private page
  File: unchanged

Dirty COW race:
  Two threads, one file-backed MAP_PRIVATE mapping

  Thread 1: madvise(addr, MADV_DONTNEED) in a loop
            → tells kernel to discard private copy, revert to file mapping

  Thread 2: write to /proc/self/mem at the mapping address in a loop
            → uses get_user_pages() with FOLL_WRITE to get the page

  Race window:
    Thread 2 calls get_user_pages(FOLL_WRITE)
    Kernel sees no private copy → triggers COW fault
    Thread 1's MADV_DONTNEED fires: discards the just-allocated private copy
    Thread 2 retries get_user_pages — now gets the *file page* directly
    Thread 2 writes via /proc/self/mem to what kernel believes is a private copy
    Kernel marks file page as dirty and writes through to backing file

The exact kernel path (simplified from mm/memory.c):

/* get_user_pages with FOLL_WRITE | FOLL_FORCE path */
retry:
    page = follow_page(vma, addr, FOLL_WRITE);
    if (!page) {
        /* COW fault - allocates private copy */
        faultin_page(vma, addr, &fault_flags);
        goto retry;  /* <- race window here */
    }
    /* Thread 1 fires MADV_DONTNEED between faultin_page and follow_page */
    /* follow_page returns the *original* read-only file page */
    /* write proceeds to file-backed page */

The race requires two threads hitting a narrow window. In practice, the window is wide enough that a userspace loop running both threads wins within seconds on any modern multi-core system.

Attack Scenario

The canonical exploit:

# As unprivileged user:
# 1. Open /etc/passwd (read-only)
# 2. Map it with MAP_PRIVATE (supposedly no write capability)
# 3. Run two threads: MADV_DONTNEED loop + /proc/self/mem write loop
# 4. Write new root-password-less entry into /etc/passwd
# 5. su to root

Real exploits from 2016 included Android rooting tools (DirtyCow-based root exploits were distributed as APKs). On Android, it was used to replace system binaries and gain persistent root access on millions of devices running kernels from 2007-2016.

Detection

Runtime detection requires kernel audit of ptrace//proc/self/mem write operations to read-only mappings
inotifywait on /etc/passwd and critical system files (noisy, imperfect)
Post-exploitation: hash-based integrity checking of system files (AIDE, Tripwire)
Kernel audit subsystem (auditctl -a always,exit -F arch=b64 -S write)
The CVE was discovered by Phil Oester who found it being exploited in the wild on a web server

Fix

Patch by Linus Torvalds, October 19, 2016 (one of the fastest critical kernel patches ever):

/* The fix: add a check for a stale COW page after MADV_DONTNEED */
/* If the page returned by follow_page is not the COW copy we expected,
   don't write to it — instead, force a new COW fault */
if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags))
    goto no_page;

The fix ensures that after a COW fault, if the page pointer becomes stale (due to MADV_DONTNEED), the write does not proceed to the original read-only page.

Lasting Architectural Changes

Kernel memory safety audits: The 9-year undetected window triggered more systematic review of mm/ subsystem races
Android security patches: Google pushed kernel patches to all supported Android devices — accelerating Android kernel patching processes
Fuzz testing of mm subsystem: syzkaller (Google, 2016) was expanded to cover get_user_pages paths
Copy-on-write path hardening: Linux 5.x added additional checks in the write-fault path

Case Study 2: Heartbleed — CVE-2014-0160

Technical Root Cause

Heartbleed is a buffer over-read in OpenSSL's implementation of the TLS heartbeat extension (RFC 6520). The heartbeat extension allows either party in a TLS session to send a "heartbeat request" containing an arbitrary payload and a length field, and the other party echoes the payload back. This is used to keep connections alive without renegotiation.

The OpenSSL implementation trusted the attacker-controlled length field without validating it against the actual payload size:

/* Vulnerable code in ssl/d1_both.c (OpenSSL 1.0.1 through 1.0.1f) */
int dtls1_process_heartbeat(SSL *s) {
    unsigned char *p = &s->s3->rrec.data[0];
    unsigned short hbtype;
    unsigned int payload;

    hbtype = *p++;
    n2s(p, payload);          /* Read attacker-controlled length (2 bytes) */
    pl = p;                    /* pl points to actual payload in packet */

    /* BUG: No check that payload <= actual packet length */

    buffer = OPENSSL_malloc(1 + 2 + payload + padding);
    bp = buffer;
    *bp++ = TLS1_HB_RESPONSE;
    s2n(payload, bp);
    memcpy(bp, pl, payload);   /* Copy 'payload' bytes from 'pl' */
    /* If payload > actual_data_length, memcpy reads beyond the packet
       into adjacent heap memory — server's heap content disclosed to attacker */
}

The attack:

Attacker sends:  [heartbeat request] [payload="A"] [length=65535]
OpenSSL reads:   [1 byte "A"] then reads 65534 more bytes from adjacent heap
OpenSSL sends:   64KB of server heap memory back to attacker
Heap may contain: TLS session keys, private RSA keys, passwords, user data

A single malformed heartbeat request returned up to 64KB of adjacent heap memory. By sending thousands of requests, an attacker could slowly map and extract large portions of the server's heap.

Scale of Impact

OpenSSL 1.0.1 (released March 2012) through 1.0.1f — two years of vulnerable versions
Estimated 500,000+ servers using vulnerable OpenSSL at disclosure (April 7, 2014)
The bug was independently discovered by: Neel Mehta (Google Security) and researchers at Codenomicon
The Codenomicon team coined "Heartbleed" and created heartbleed.com for public communication
Yahoo's servers were confirmed compromised within hours of public disclosure
Cloudflare published a challenge to prove private key extraction — successfully exploited within hours

Detection

At time of disclosure: no detection was possible from server logs alone. The heartbeat extension generated no application-level log entries and left no trace in TLS session records.

Post-disclosure detection: - Network IDS signatures matching the malformed heartbeat pattern - OpenSSL's own heartbleed_test.py (released by Filippo Valsorda) - SIEM correlation of unusual TLS traffic patterns - Many CDNs and load balancers detected the pattern and blocked it at the edge within 48 hours

Fix

Two-line fix by Stephen N. Henson (OpenSSL core team):

/* Added bounds check before allocation */
if (1 + 2 + payload + padding > s->s3->rrec.length) {
    /* Malformed heartbeat — payload larger than record */
    return 0;
}

OpenSSL 1.0.1g released April 7, 2014 — same day as public disclosure.

Lasting Architectural Changes

OpenSSF founding: The vulnerability's severity (a critical cryptographic library with a trivial missing bounds check, undetected for 2 years) catalyzed the founding of the Open Source Security Foundation (OpenSSF) in 2020 — consolidating security efforts across the Linux Foundation, Google, Microsoft, IBM, and others
Memory-safe TLS libraries: Rustls (TLS in Rust) emerged as a direct response. AWS's s2n-tls used bounded memory allocators specifically to prevent this class of bug
Certificate mass revocation: The event stress-tested certificate revocation infrastructure (CRL, OCSP) and found it inadequate — motivating Certificate Transparency (RFC 6962)
Private key rotation procedures: Most organizations lacked documented key rotation runbooks before Heartbleed. Post-2014, key rotation is standard incident response procedure
LibreSSL fork: The OpenBSD team forked OpenSSL into LibreSSL (2014), removing 90,000 lines of dead code and adding stricter bounds checking throughout

Case Study 3: Linux Kernel Use-After-Free Bugs

Technical Root Cause

Use-after-free (UAF) is the class of bugs where a pointer to freed memory is subsequently dereferenced. In the kernel, freed memory may be reallocated to another kernel object. When the stale pointer is dereferenced, it reads or writes to a different, live kernel object — enabling type confusion, arbitrary write primitives, or privilege escalation.

CVE-2022-0185 — cgroup v2 fsconfig UAF:

/* Simplified vulnerable path in fs/fs_context.c */
struct legacy_fs_context {
    char *legacy_data;  /* heap-allocated data */
    ...
};

/* legacy_parse_param() appended to legacy_data */
/* On error in a nested call, legacy_fs_context_free() freed legacy_data */
/* But the pointer in the context was not nulled */
/* Subsequent call to legacy_parse_param() appended to the freed buffer */

/* Result: heap spray on freed slab object */
/* By triggering at the right time, attacker controls what the freed 
   legacy_data pointer now points to (another slab object) */
/* Writing "parameter data" overwrites that object */

CVE-2022-0185 was discovered by the Crusaders of Rust (a CTF team) and disclosed in January 2022. It allowed unprivileged users (with CAP_SYS_ADMIN in a user namespace — which unprivileged users can create on most distributions) to escalate to root.

CVE-2021-4154 — cgroup1 write UAF:

A write to /proc/<pid>/cgroup triggered a UAF in cgroup1's open/write path. The file handle's private data (css_set) was freed during the write operation if a concurrent fork() caused a cgroup migration, but the file operation continued using the stale pointer.

Exploitation pattern common to kernel UAFs:

Step 1: Allocate target object T in slab cache X
Step 2: Get reference to T (stale pointer P)
Step 3: Free T — slab allocator marks slot as free
Step 4: Spray slab cache X with attacker-controlled data (same size as T)
        → freed slot now contains attacker's fake object
Step 5: Dereference P → accesses attacker's fake object
Step 6: Fake object contains fake function pointer or kernel data pointer
Step 7: Code execution or arbitrary kernel read/write

Detection

Kernel Address Sanitizer (KASAN): Compile-time instrumentation that catches UAF at runtime. Every heap allocation/free is tracked; accessing freed memory triggers a report.
KMSAN: Kernel Memory Sanitizer — detects uninitialized memory reads
Syzbot: Google's continuous fuzzing infrastructure running syzkaller with KASAN on all Linux kernel branches — finds ~1500 bugs/year, most before disclosure
Static analysis: Clang's -fsanitize=address for kernel sanitizers, CodeChecker with Clang Static Analyzer

Fix Patterns

Null pointer on free: Set pointer to NULL after freeing to catch use-after-free on null dereference
Reference counting: Use kref (Linux kernel reference counter) to prevent freeing while references exist
RCU for read paths: Read-Copy-Update ensures readers always see either old or new pointer, never freed memory
Hazard pointers: Lock-free mechanism for safe concurrent access

Lasting Architectural Changes

User namespace restrictions: Many distributions (Ubuntu 22.04+, RHEL 9) now restrict unprivileged user namespace creation by default (kernel.unprivileged_userns_clone=0) because it is required for most recent kernel UAF exploits
slab randomization: CONFIG_SLAB_FREELIST_RANDOM and CONFIG_SLAB_FREELIST_HARDENED make heap spray harder
KASLR: Kernel ASLR randomizes kernel base and heap layout

Case Study 4: AWS EBS Silent Data Corruption (2011)

Technical Root Cause

The April 2011 AWS us-east-1 outage (see also 06-cloud-outage-postmortems.md) included a component that preceded and contributed to the cascade: a silent data corruption bug in EBS (Elastic Block Store) that was discovered in the post-mortem.

EBS volumes in 2011 were multi-node systems where data was replicated across multiple storage nodes. The corruption mechanism involved a race condition in the write path during node recovery:

Normal write path:
  Client writes block B to primary node P
  P replicates to replica node R
  P acknowledges write to client after R confirms

Race during node recovery:
  P is recovering (rejoining after brief network partition)
  P is "catching up" by replaying uncommitted writes from a log
  Simultaneously, new writes arrive from clients

  Race condition:
    Replay of old write W_old and new write W_new target same block
    Due to a missing lock in the recovery path, W_old and W_new 
    interleave at byte level during log replay
    Result: block contains partial data from W_old and partial from W_new
    Neither checksum passes (corruption detected) or checksum not computed
    (silent corruption)

The specific race was in the EBS log replay during a "reconstitution" operation — when a storage node rejoined after a brief outage and needed to catch up on missed writes. The reconstitution path had a lock-order bug that allowed concurrent writes to be applied to the same block during replay.

Write amplification aspect: The race was only triggered when write amplification was high — specifically when log replay and live writes were both targeting the same block at high frequency. This made it difficult to reproduce in testing.

Detection

Detected during post-incident review by correlating customer data integrity complaints with storage node reconstitution events
Customers running databases (PostgreSQL, MySQL) detected corruption via fsck and database checksum failures
EBS itself did not have end-to-end block checksums at the time — a critical gap

Recovery

Affected volumes were identified by correlating reconstitution event timestamps with write patterns
Snapshots taken before the corruption event were used to restore
Some data loss was unavoidable for customers who did not have pre-event snapshots

Architectural Lessons

End-to-end block checksums are non-negotiable. Modern EBS uses checksums at every layer. The absence of checksums allowed silent corruption to go undetected.
Recovery paths must be held to the same correctness standards as normal paths. The reconstitution path had weaker locking than the normal write path — a common pattern in complex distributed systems.
This event directly contributed to the EBS architectural redesign that led to the modern EBS backend (built on principles similar to the Dynamo paper), with stronger consistency guarantees and checksum-validated replication.

Case Study 5: Rowhammer Attack (2014)

Technical Root Cause

Rowhammer is a hardware-level vulnerability in DRAM (Dynamic Random Access Memory) that allows unprivileged software to flip bits in memory it does not own. It requires no software bug — it exploits a physical property of DRAM cells.

DRAM structure:

DRAM organized as a grid of rows and columns:

Row 0: [cell][cell][cell]...[cell]
Row 1: [cell][cell][cell]...[cell]  ← target row
Row 2: [cell][cell][cell]...[cell]
Row 3: [cell][cell][cell]...[cell]

Each cell: a capacitor + transistor
Capacitor charge represents 0 or 1
Capacitor leaks charge over time → must be refreshed every 64ms (JEDEC standard)

Physical coupling between adjacent rows:
  Repeatedly accessing Row 0 and Row 2 (aggressor rows)
  causes electromagnetic disturbance in Row 1 (victim row)
  If disturbance exceeds threshold, a bit in Row 1 flips

Attack mechanism:

/* Rowhammer proof-of-concept (simplified) */
void hammer(volatile uint64_t *a, volatile uint64_t *b) {
    for (int i = 0; i < 10000000; i++) {
        *a;  /* access row N */
        *b;  /* access row N+2 */
        asm volatile("clflush (%0)" : : "r"(a)); /* flush cache line */
        asm volatile("clflush (%0)" : : "r"(b));
        asm volatile("mfence");
    }
    /* Row N+1 bits may have flipped */
}

By hammering rows adjacent to a page table page (which maps attacker's own memory), an attacker can flip a bit in a page table entry. A single bit flip in a page table can change a physical address mapping, giving the attacker read/write access to arbitrary physical memory — including kernel pages.

Privilege escalation path:

Attacker allocates large memory regions to influence physical layout
Identifies two physical pages adjacent to target page table row
Hammers those two pages 10M+ times
Bit in page table entry flips
Attacker now has read/write to kernel memory
Writes shellcode to kernel memory
Escalates to root

The original rowhammer paper (Kim et al., 2014) demonstrated bit flips on 110 out of 129 tested DRAM modules from three major manufacturers.

Variants: - Single-sided rowhammer: Hammer one row, flip adjacent row - Double-sided rowhammer: Hammer both neighbors of target row (more reliable) - Rowhammer.js (2016): Browser-based rowhammer via JavaScript without clflush — using cache eviction patterns instead - GLitch (2018): GPU-based rowhammer via WebGL - Half-Double (2021, Google Project Zero): Rowhammer that skips one row, exploiting DRAM charge coupling at greater distances - TRRespass (2020): Bypasses Target Row Refresh (TRR) mitigations by using many-sided hammering patterns

Detection

Runtime detection is extremely difficult — the attack looks like normal memory access
Hardware performance counters can detect high cache miss rates correlating with rowhammer, but this is imprecise
Google's rowhammer-test tool tests DRAM for susceptibility

Fix

Hardware mitigations: - ECC (Error-Correcting Code) DRAM: Can correct 1-bit errors, detect 2-bit errors. Provides partial protection but does not prevent all rowhammer attacks (Flip Feng Shui attack bypasses ECC by targeting specific bit positions) - Target Row Refresh (TRR): DRAM manufacturers added TRR in DDR4 as a proprietary mitigation — tracks frequently-accessed rows and refreshes neighbors. TRRespass demonstrated bypass. - LPDDR5 DRAM (2020): Refresh Management (RFM) — a JEDEC standard mechanism for the memory controller to request additional refreshes when row access rates are high - pTRR (per-DIMM TRR standardization): Industry effort post-2020 to standardize TRR as part of the JEDEC spec

Software mitigations: - Memory isolation: Ensure page tables are not physically adjacent to untrusted memory (kernel address isolation efforts) - KPTI (Kernel Page Table Isolation): Originally for Meltdown, also reduces rowhammer attack surface by separating kernel and user page tables - Huge pages: Using 2MB huge pages makes it harder to achieve the precise physical layout needed for rowhammer exploitation

Lasting Architectural Changes

Hardware security is not separate from software security. Rowhammer proved that a software security model can be broken by hardware physics — forcing a re-evaluation of the trusted computing base
ECC memory in consumer systems: Pressure to add ECC to non-server DRAM increased significantly after Rowhammer
Browser sandboxing hardened: Firefox and Chrome reduced timer precision (performance.now() resolution lowered to 1ms, then 100μs with site isolation) to make browser-based rowhammer timing harder
Hardware Root of Trust requirements: Cloud providers began requiring ECC DRAM for all new server procurement

ASCII Diagram: Memory Corruption Classes

Stack Layout (vulnerable C program):
  High address
  ┌─────────────────┐
  │   argv, envp    │
  ├─────────────────┤
  │   stack frame   │
  │   saved RIP     │ ← overwrite this to redirect execution
  │   saved RBP     │
  │   local vars    │
  │   buffer[64]    │ ← memcpy(buffer, user_input, user_len) with no bounds check
  ├─────────────────┤
  │   heap          │
  │   malloc chunks │ ← use-after-free: access chunk after free()
  │                 │ ← double-free: free() same chunk twice
  ├─────────────────┤
  │   BSS/data      │
  ├─────────────────┤
  │   text (code)   │
  Low address

Heartbleed (heap over-read):
  [TLS record buffer]
  [other heap data: private keys, passwords, session tokens]
                         ↑
  memcpy(response, payload_ptr, attacker_length)
  reads beyond record into adjacent heap allocation

Debugging Notes

# KASAN (Kernel Address Sanitizer) output
BUG: KASAN: use-after-free in path/to/file.c:line
Read of size 8 at addr ffff888104c3b200 by task process/pid
Call Trace: [stack trace showing the bad access]
Allocated by task N: [allocation stack trace]
Freed by task M: [free stack trace]

# Check for Heartbleed vulnerability
openssl version -a  # check for < 1.0.1g or >= 1.0.2

# Test for rowhammer susceptibility
git clone https://github.com/google/rowhammer-test
./rowhammer_test  # WARNING: may cause system instability

# Check ECC status on Linux
edac-util -s 4  # requires edac-utils package
# or
dmidecode -t memory | grep -i ecc

# Address Sanitizer for userspace programs
gcc -fsanitize=address,undefined -g program.c -o program
./program  # ASan will report any memory errors

Security Implications

Heartbleed: complete private key compromise → all past TLS sessions retroactively decryptable (if attacker logged traffic)
Dirty COW: local privilege escalation on any Linux system (Android, server, embedded) from 2007-2016
Kernel UAF: local privilege escalation on modern Linux (requires user namespace on most distros)
Rowhammer: privilege escalation without any software vulnerability — hardware physics only
EBS corruption: potential data loss for customers — reputational and SLA impact for AWS

Performance Implications

KASAN adds ~2x memory overhead and 2-10x CPU overhead — production use requires selective deployment
ECC DRAM has ~2% lower bandwidth than non-ECC (additional error correction circuitry)
TRR (Target Row Refresh) reduces DRAM throughput by ~1-5% due to additional refresh operations
KPTI (Meltdown mitigation) adds 5-30% syscall overhead depending on workload

Failure Modes

Vulnerability	Trigger	Detection Signal	CVSS
Dirty COW	Race: madvise + /proc/self/mem write	System file modification	7.8
Heartbleed	Malformed TLS heartbeat	Server memory in responses	7.5
CVE-2022-0185	Malformed fsconfig syscall	Kernel UAF, potential panic	8.8
EBS corruption	Write during node reconstitution	fsck errors, DB checksum fail	N/A
Rowhammer	High-frequency DRAM row access	Bit flips in memory	7.0

Modern Usage and Mitigations

Rust eliminates UAF, double-free, buffer overflow at compile time — zero CVEs of these classes in safe Rust
CFI (Control Flow Integrity): Android uses LLVM CFI; Linux 6.1+ supports fine-grained CFI. Prevents exploitation of memory corruption for code redirection
MTE (Memory Tagging Extension): ARM v8.5-A hardware feature. Tags each pointer and allocation; hardware traps mismatched access. Catches UAF and buffer overflow at minimal overhead (~1%). Available in Google Pixel 6+
Sealed kernel memory: Linux 5.18+ vm_flags sealing prevents remapping of kernel text

Future Directions

DDR5 with RFM (Refresh Management): JEDEC standard (2020) provides a standardized protocol for the memory controller to request proactive refreshing — partially addresses rowhammer
Memory-safe OS kernels: Linux's Rust integration (6.1+) aims to prevent new memory safety bugs in new driver code
Hardware memory tagging at scale: Apple M1/M2 chips have Pointer Authentication Codes (PAC) for return addresses. ARM MTE in production Android devices
CHERI architecture: Cambridge Hardware Enhanced RISC Instructions — hardware capability pointers that enforce bounds and permissions at the CPU level. Morello prototype (ARM, 2022) demonstrated full capability isolation

Exercises

Reproduce a buffer overflow in a small C program. Use gcc -fno-stack-protector -z execstack to disable mitigations. Use GDB to inspect the stack, overwrite the return address, and redirect execution. Then re-enable stack canaries and observe the protection.
Write a program that demonstrates use-after-free. Compile with AddressSanitizer (-fsanitize=address). Observe the detailed ASan report. Then fix the bug and confirm ASan is clean.
Use the OpenSSL Heartbleed proof-of-concept from GitHub (many exist for CVE-2014-0160) against a vulnerable OpenSSL in a Docker container. Observe what data is leaked from the heap. (Legal and controlled environment only.)
Set up KASAN in a Linux kernel build (CONFIG_KASAN=y). Write a simple kernel module with a deliberate UAF. Observe the KASAN report including allocation and free stack traces.
Research the Spectre and Meltdown vulnerabilities (2018). How do they relate to rowhammer? What does it mean that hardware-level attacks can bypass software security boundaries?

References

Oester, Phil. "CVE-2016-5195 - Dirty COW." Red Hat Security Advisory RHSA-2016:2098, October 2016.
Torvalds, Linus. Kernel patch: "mm: remove gup_flags FOLL_WRITE games from __get_user_pages()." git.kernel.org, October 19, 2016.
Mehta, Neel; Codenomicon. "Heartbleed Bug." heartbleed.com, April 7, 2014.
Kim, Yoongu et al. "Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors." ISCA 2014.
Google Project Zero. "Exploiting the DRAM rowhammer bug to gain kernel privileges." March 2015.
van der Veen, Victor et al. "Drammer: Deterministic Rowhammer Attacks on Mobile Platforms." ACM CCS 2016.
Frigo, Pietro et al. "TRRespass: Exploiting the Many Sides of Target Row Refresh." IEEE S&P 2020.
AWS Post-mortem: "Summary of the Amazon EC2 and Amazon RDS Service Disruption." aws.amazon.com/message/65648, April 2011.
Linux kernel CVE database: cve.mitre.org; kernel.org/doc/html/latest/admin-guide/security-bugs.html