Memory Corruption¶
An effective memory-safety-violating write that actually changes stored program contents beyond a valid access, bounds, ownership, or lifetime constraint.
Core Idea¶
Memory corruption occurs when a write crosses a valid memory-safety boundary and actually changes stored program contents. The boundary may be the end of a live object or the end of an allocation's lifetime. The changed target may be data, a pointer, a field, or diagnostic guard bytes. An invalid access report alone shows that a rule may have been broken; it does not always show that memory was changed.[ref-6496632d61fe][ref-3c3bdcfc4857][^ref-09d3fb0c770d]
This entry separates four things: the weakness that permits a bad write, the effective write, the changed memory state, and what is noticed later. A crash or successful exploit is possible but not required. An ordinary permitted in-bounds assignment that stores the wrong application value is a different kind of mistake because no memory-safety permission was crossed.[ref-ec5aad017456][ref-7e703a273f11][^ref-6496632d61fe]
Use Within the Domain¶
To assess a case, ask: What memory was allowed to be written? Which write went beyond that permission? What contents actually changed? A read after free may disclose data or fault without changing memory. A protected page may stop an attempted write. A changed sentinel pattern, by contrast, can reveal that watched storage was modified, even if the checker runs later than the write.[ref-23c4dea8ff1b][ref-09d3fb0c770d]
The current DAG records Memory Corruption as a specific Failure of a memory-safety criterion. It presupposes Boundary, because the claim that a write is invalid needs a permitted range or lifetime. These relations are distinct from the cause: a buffer overflow is one way to reach the state, not the entire class.
Clarity¶
“Buffer overflow,” “corrupted memory,” and “segmentation fault” do not mean the same thing. Buffer overflow identifies a write past a buffer's valid end. Corrupted memory identifies changed contents from an effective violating write. A segmentation fault can report a denied access before that attempted write changes a target. Keeping these claims separate prevents a possible consequence from being reported as a proven one.[ref-ec5aad017456][ref-09d3fb0c770d]
Manages Complexity¶
The three questions—permission, effective write, changed target—organize heap layout, pointer reuse, guard behavior, and later symptoms. In Project Zero's Zoom investigation, the important changed target was a neighboring C++ heap object, while allocator behavior affected whether that change led to a useful virtual call. In an Android kernel proof of concept, the relevant later target was the task_struct.addr_limit field.[ref-6496632d61fe][ref-3c3bdcfc4857]
Abstract Reasoning¶
A vulnerability category points to what might happen. Evidence of changed storage supports a narrower, stronger conclusion: an effective write reached that target. A guard-page fault supports an attempted protected access but does not by itself prove that the attempted write changed memory. This tells an investigator whether to repair a bounds calculation, an object-lifetime error, or first obtain better evidence of the changed target.[ref-ec5aad017456][ref-7e703a273f11][^ref-09d3fb0c770d]
Knowledge Transfer¶
The test transfers between a live buffer overrun and a stale-pointer chain because both have a permitted memory region, a crossing write, and a changed result. The code and storage differ; the classification questions remain the same. The word “corruption” is used in other subjects, but the specific access, lifetime and program-memory roles do not transfer outside software by metaphor alone.[ref-6496632d61fe][ref-3c3bdcfc4857]
Example¶
In Project Zero's Zoom MMR experiment, CVE-2021-34423 allowed an overflow to alter a neighboring heap object's memory. The researcher obtained control of a virtual-call pointer in some trials, but did not finish the further address-leak step of a reliable exploit. The live buffer had a valid extent; the write crossed it; the adjacent object changed.[^ref-6496632d61fe]
In the researchers' Android Binder proof of concept, a first use-after-free phase used writes to reused iovec state and leaked a task_struct address. A second phase redirected a write and changed task_struct.addr_limit to 0xFFFFFFFFFFFFFFFE. This published PoC is not proof that a suspected in-the-wild exploit used the same mechanism. The expired object lifetime and the later changed kernel field fill the same permission-and-result roles as the Zoom case.[^ref-3c3bdcfc4857]
Relationships to Other Abstractions¶
Current abstraction Memory Corruption Domain-specific
Parents (2) — more general patterns this builds on
-
Memory Corruption is a kind of Failure Prime
Actual alteration of program memory by a violating write is a specific failure of an applicable memory-safety criterion.
-
Memory Corruption presupposes Boundary Prime
A corrupting write is defined relative to a valid program-memory access boundary that it crosses.
Hierarchy paths (2) — routes to 2 parentless roots
- Memory Corruption → Failure
- Memory Corruption → Boundary
Neighborhood in Abstraction Space¶
Memory Corruption sits in a sparse region of the domain-specific corpus (92nd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Program Execution & Runtime Concepts (34 abstractions)
Nearest neighbors
- Buffer Overflow — 0.82
- Memory Management — 0.79
- Pointer — 0.78
- Object graph — 0.78
- No-Force Policy — 0.78
Computed from structural-signature embeddings · 2026-10-17
Not to Be Confused With¶
- Out-of-bounds write or use after free: each is a possible route; the label alone does not establish a particular changed target.[ref-ec5aad017456][ref-7e703a273f11]
- Invalid read: Clang's example detects a read after free, but that read alone does not demonstrate modified contents.[^ref-23c4dea8ff1b]
- Segmentation fault: a protection event that may stop the write before memory changes.[^ref-09d3fb0c770d]
- Data-integrity error: a wrong value written through a valid, in-bounds application operation may matter greatly without meeting this memory-safety definition.
References¶
[^ref-6496632d61fe]: Natalie Silvanovich, “Zooming in on Zero-click Exploits,” Project Zero, January 18, 2022, https://projectzero.google/2022/01/zooming-in-on-zero-click-exploits.html. Original researcher account; the MMR heap investigation, adjacent-object overwrite, virtual-call pointer, and unfinished later leak appear in the Zoom MMR analysis.
[^ref-3c3bdcfc4857]: Maddie Stone, “Bad Binder: Android In-The-Wild Exploit,” Project Zero, November 2019, https://projectzero.google/2019/11/bad-binder-android-in-wild-exploit.html. Original researcher account of a proof of concept; see “Exploiting the Use-After-Free,” “Overwriting the Address Limit,” and “In-the-Wild Analysis.” The authors distinguish the PoC from the suspected wild exploit.
[^ref-09d3fb0c770d]: Microsoft, “Application Verifier - Stop Codes - Basics,” https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/application-verifier-stop-codes-basics. Vendor diagnostic documentation; see CORRUPTED_FREED_HEAP_BLOCK, CORRUPTED_HEAP_BLOCK_SUFFIX, and FIRST_CHANCE_ACCESS_VIOLATION. No universal timing claim is inferred.
[^ref-ec5aad017456]: MITRE, “CWE-787: Out-of-bounds Write,” https://cwe.mitre.org/data/definitions/787.html. Authoritative weakness taxonomy, Description and Common Consequences; a category does not prove a particular changed target.
[^ref-7e703a273f11]: MITRE, “CWE-416: Use After Free,” https://cwe.mitre.org/data/definitions/416.html. Authoritative weakness taxonomy, Description and Common Consequences; distinguishes possible writes, reads, and crashes.
[^ref-23c4dea8ff1b]: LLVM/Clang, “AddressSanitizer,” https://clang.llvm.org/docs/AddressSanitizer.html. Tool documentation, heap-use-after-free READ of size 4 example; used only as a negative boundary for actual changed memory.