Memory Corruption¶

An effective memory-safety-violating write that actually changes stored program contents beyond a valid access, bounds, ownership, or lifetime constraint.

Version: v1 · 2026-10-17 · History
Domain-specific #: 14218
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomains: Memory Safety, Systems Security → Computer Science & Software Engineering
Aliases: Memory corrupting write

Core Idea¶

Memory corruption is a changed state of program memory produced by a write that crosses a valid memory-safety boundary. The relevant boundary may be the end of a live object, the lifetime of an allocation, or the access a component is entitled to make. The write must actually reach storage and change contents. A vulnerability that could write out of bounds is a route to corruption, while a read-only violation or a write stopped by memory protection does not itself establish a changed-memory instance.^[1]^[2]^[3]^[4]^[5]

The distinction matters because cause, state, detection, and consequence can occur at different moments. In an investigation of a Zoom multimedia router, an out-of-bounds write changed a neighboring C++ heap object's memory; in some trials the researcher controlled a virtual-call pointer. In a separate Android Binder proof of concept, a use-after-free sequence culminated in an overwrite of task_struct.addr_limit. The first route crossed a live buffer's extent; the second used an expired object's storage to redirect a later kernel write. Their common result was changed memory outside the authorized operation's target, not the particular vulnerability class or the later exploit path.^[1]^[2]

Here memory-safety boundary is narrower than “the program behaved differently than intended.” An ordinary authorized in-bounds assignment that stores the wrong application value may be a serious logic or data-integrity error, but it is not automatically this memory-corruption predicate. Conversely, no attacker, crash, or successful exploit is required once the violating write and changed target are established.^[3]^[4]^[1]

Structural Signature¶

A memory bearer. Identify the live object, reallocated region, guard bytes, or control field whose contents can be compared before and after the event. Without a target, “corruption” is only a risk label.^[1]^[2]^[5]
A valid-access boundary. Bounds, lifetime, ownership, or equivalent memory permission specifies which operation could legitimately write which location. The Zoom buffer boundary and the freed Binder object supply unlike instances.^[1]^[2]
A crossing write. A write proceeds through an invalid access path and reaches a location beyond that permission. A trapped attempt can be a memory-safety violation without a completed corruption event.^[3]^[4]^[5]
Changed stored content. The target's bytes, pointer, guard pattern, or field value actually differ because of the write. This result, rather than the label of the weakness, makes the event memory corruption.^[1]^[2]^[5]
An optional observation path. A later call may consume the altered pointer; a verifier may compare a changed guard pattern; an exception may instead reveal an attempted access before modification. Observation helps diagnose the state but is not part of what caused it.^[1]^[5]

These roles prevent an invalid access, an actual alteration, and a detected symptom from being treated as interchangeable. They also leave room for different memory regions and detection times without making one implementation's layout universal.

What It Is Not¶

Not every out-of-bounds write report. CWE-787 describes a weakness that can modify memory or crash. To establish a particular corruption instance, show the write reached a target and altered it. A protected boundary may stop it first.^[3]^[5]
Not every use after free. A stale pointer can be used for a read, a write, or an access that faults. Clang's published AddressSanitizer example is a heap-use-after-free read; it demonstrates detection of an invalid access, not changed contents by that read.^[4]^[6]
Not identical to a segmentation fault. A fault is an observed protection event. It can occur at a guard page before the offending write changes memory. A changed sentinel that is discovered later is a different diagnostic course.^[5]
Not any incorrect value in memory. This entry requires a write beyond a valid memory-safety permission. A permitted assignment based on a wrong business rule can corrupt an application's data in an everyday sense, but it lacks the specific boundary crossing analyzed here.
Not proof of exploitation. Altered memory can be a useful exploitation primitive, a crash cause, a detected guard mismatch, or a latent state. The Zoom investigator obtained occasional virtual-call control but did not finish the address-leak step of her planned reliable exploit.^[1]

Scope of Application¶

The literal scope is software execution in which memory objects or locations have meaningful access, extent, and lifetime constraints. Heap allocations, kernel structures, adjacent objects, and diagnostic guard patterns all provide possible bearers. The entry applies to an actual changed-memory event in such a setting; the source examples do not license a claim that every language runtime or architecture exposes the same mechanisms.^[1]^[2]^[5]

At a live buffer boundary, a completed out-of-bounds write can change an adjacent object's contents. Across an allocation lifetime, a stale reference may operate on storage now used for another purpose, and a later effective write can change current state. Monitoring tools can add sentinel bytes or inaccessible pages: a changed sentinel evidences a past alteration, while an inaccessible page can stop access before one. The classification follows what happened to stored state, not the diagnostic tool chosen.^[1]^[2]^[5]

Clarity¶

The entry resolves a common ambiguity in incident descriptions. “A buffer overflow occurred,” “the heap was corrupted,” “the program crashed,” and “an exploit worked” make different claims. The first names an invalid-write route; the second, if verified, names altered memory; the third names a symptom; the fourth names an achieved adversarial outcome. An investigator can therefore report the strongest supported statement without silently promoting a possible consequence to an observed one.^[3]^[1]^[5]

Manages Complexity¶

Many low-level details—allocator bins, object layout, pointer arithmetic, sanitizer configuration, and later control flow—can be organized around three questions: What was the permitted write region? Which write crossed it? What target changed? The observation path is a fourth diagnostic question. In the Zoom case, heap layout and verifier behavior affected whether the already altered object led to a useful virtual call; they did not redefine what a corrupting write is. In the Binder PoC, several UAF-assisted operations mattered, but the specific addr_limit overwrite identifies the later changed state at issue.^[1]^[2]

Abstract Reasoning¶

The classification supports a bounded inference from evidence to state. A changed guard pattern after a run supports that a write reached the watched storage, though it may not identify the precise earlier instruction. An immediate guard-page access violation supports that an invalid access was attempted at a protected boundary; without a separately demonstrated changed target, it does not prove that that access corrupted memory. A weakness classification alone supplies a plausible mechanism to investigate rather than the conclusion that memory was actually changed.^[5]^[3]^[4]

This reasoning also guides repair. If the target changed because a live buffer's bounds were crossed, examine the copy or index and the boundary check. If expired ownership allowed a write into reused storage, examine lifetime and alias management. If the only report is a read or trapped write, keep the investigation open while describing that evidence accurately.^[1]^[2]^[6]

Knowledge Transfer¶

Within software security, transfer the boundary–effective write–changed target analysis from one memory region to another. It works for a neighboring heap object and for a kernel field reached through a stale-pointer chain because it asks which permission was violated and which contents changed, not whether the same allocator or attack tool was used. The detection question transfers separately: a guard mismatch and a fault can both be useful evidence, yet they warrant different claims about state.^[1]^[2]^[5]

Across other fields, “corruption” may mean damaged data or compromised governance. That resemblance is analogy; those uses do not import memory addresses, object lifetimes, access permissions, or effective writes. The portable lesson is evidential discipline about a cause and its observed result, while this named entry remains anchored to program memory.

Examples¶

Canonical: altered neighboring Zoom heap object¶

In Project Zero's experimental investigation of CVE-2021-34423, an attacker-controlled overflow size let the researcher reach a C++ object adjacent to an MMR server heap buffer. She reports corrupting the adjacent object's memory and, with a particular allocation size, controlling a virtual-call pointer in about one in ten triggers. The heap verifier often stopped the process before the virtual call. She did not complete the further address-leak step needed for her planned reliable exploit; that limit should not be erased by the observed overwrite.^[1]

Mapped back: the live buffer's extent was the valid-access boundary; the overflow was the crossing write; the adjacent object and virtual-call pointer were changed targets; verifier crashes or pointer control were observations and consequences, not required elements of every instance.

Applied: Android Binder proof-of-concept field overwrite¶

Project Zero's Android Binder PoC reused a freed binder_thread allocation as an I/O vector. Its first UAF-assisted phase used list_del writes to reused iovec state and leaked a task_struct address. A second invocation redirected a recvmsg write to task_struct.addr_limit, which the paper traces to the value 0xFFFFFFFFFFFFFFFE. The authors explicitly say their PoC need not be the mechanism used in suspected in-the-wild exploitation; they did not have a wild exploit sample.^[2]

Mapped back: the expired binder_thread lifetime supplied the invalid-access boundary; the second redirected write was effective; task_struct.addr_limit was the demonstrably overwritten target. The initial address leak enabled the PoC chain but is not itself evidence of that later field change. The first phase also wrote iovec state, so it should not be labeled purely read-only.

Structural Tensions¶

T1: Early trap versus evidence of a completed write. In Microsoft's verifier, an inaccessible page can stop an overrun and preserve a current stack; a writable sentinel may instead be changed and discovered at a later check. The first helps localize an attempted access, while the second demonstrates altered watched contents but may separate detection from cause. This is a diagnostic design tension, not a feature every corruption event contains. Diagnostic: Does this report show a stopped access or a comparison with changed storage, and what can it locate about the write?^[5]

T2: Local state proof versus broad weakness classification. Classifying CWE-787 or CWE-416 finds candidate routes efficiently, but that breadth cannot establish changed bytes in a particular execution. Proving the exact target narrows the claim and can demand harder instrumentation or reconstruction. Diagnostic: Is the present evidence only a vulnerability class, or does it identify a modified memory bearer?^[3]^[4]

T3: Domain autonomy versus generic reduction. The event can be described generically as a boundary breach followed by a changed state, which helps compare failures. Reducing it entirely to that generic pattern loses the access rules, object lifetime, and program-memory observables that make the security diagnosis discriminating. Preserving only low-level exploit detail loses the reusable class shared by overflow and UAF. Diagnostic: Which memory-specific permission and changed target make the generic pattern useful here?

Structural–Framed Character¶

The entry has a structural center: two unlike software cases preserve a valid-access boundary, an effective violating write, and changed memory. It is not merely a label for the Zoom object, the Android kernel, or one tool's stop code. Its boundary is also specific: neither a UAF read nor a blocked invalid write fills the changed-state role, and an authorized wrong-value assignment does not fill the violated memory-safety boundary.^[1]^[2]^[6]^[5]

The frame is computer science and software security. Human-practice dependence enters when people design access rules, programming languages, instrumentation, and response thresholds; the changed-memory event itself can occur without a human observer or attacker. Institutional origin is not an organization, legal rule, or office: the sources use a technical software-failure category, and this entry does not invent a narrower institutional genealogy. Vocabulary travel is limited: “corruption” and “boundary” can be said elsewhere, but addresses, allocations, effective writes, and object lifetimes do not travel as the same mechanism. Import versus recognition: a new heap or kernel case is recognized as the same pattern when those roles recur; calling an altered financial record or compromised official “memory corruption” would import the software vocabulary metaphorically. The concept is descriptive of a failure state and evaluatively negative because memory-safety permissions were breached, but it does not itself assert malicious intent or a successful exploit. Its character: a reusable, causally precise software-failure state with a strong internal structure and an irreducible program-memory frame.

Structural Core vs. Domain Accent¶

What could lift: a permitted boundary, an operation crossing it, and an observed changed state form a generic causal skeleton. The existing Boundary Prime handles the demarcation and crossing rule; Constraint handles admissible versus inadmissible operations; Failure handles a breached applicable requirement. Their composition, rather than a new proposed Prime called “generic corruption,” carries the portable analysis. The evidential rule—do not equate a possible cause with an observed result—is also portable.

What stays in the domain: a memory object has a concrete addressable extent and lifetime; a write can land in adjacent or reused storage; changed pointers or fields can be consumed by later execution. These are not decoration on the name. Remove those facts and the difference among a read-only UAF, a stopped overflow, and an actual overwrite disappears.^[1]^[2]^[6]^[5]

Why this fails the Prime bar: the named memory-corruption identity requires addressable program memory, a memory-validity rule such as bounds or lifetime, an effective write, and changed stored contents. Remove those and the positive cases cease to instantiate memory corruption. Elsewhere, “corruption” can denote inaccurate records, an altered material, or abuse of entrusted power, but those events have different permissions and mechanisms. The general relation is already expressed by the accepted Boundary–Constraint–Failure composition. Importing this name into another field is an analogy, not the same abstraction.

This entry presupposes Boundary and is a kind of Failure.

The current DAG records two typed relations. Memory Corruption presupposes the live Boundary Prime because its invalidity requires a meaningful permitted-write demarcation; it is a specific failure because a memory-safety criterion has been breached and stored contents have changed. The live Constraint Prime provides related language for admissible operations, but no separate typed edge is asserted. Data Integrity is a tempting neighbor because changed contents can impair correctness; its preservation and verification roles do not make it an all-instance parent of this changed-state event.^[3]^[4]^[5]

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

Show alternative path (1)

Neighborhood in Abstraction Space¶

Memory Corruption sits in a sparse region of the domain-specific corpus (92^nd 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¶

Buffer overflow names a bounds-crossing route, often an invalid write past an object's end. It can cause corruption when it completes and changes another target, but the route and the resulting state answer different questions. Use after free names an expired-lifetime access; it can be a read, a write, or a detected attempt. Segmentation fault names a protection failure event and may prevent a write from taking effect. Memory management names allocation and reclamation practices. None of these alone asserts the changed-memory result across both bounds and lifetime routes.^[3]^[4]^[6]^[5]

References¶

[1] 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. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q

[2] 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. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m

[3] 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. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i

[4] 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. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h

[5] 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. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q

[6] 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. registry ↩a ↩b ↩c ↩d ↩e