Introduction

The Wrong Memory

The objective of this book is to develop a particular way of understanding memory-safety bugs in the C programming language. For the purposes of this book, memory safety concerns whether accesses remain valid with respect to objects, bounds, storage, and lifetimes.

C emerged from a design context in which close control over machine resources was a feature rather than an anomaly. Its relatively low-level memory model allows programmers to manipulate objects through pointers and pointer arithmetic without generally requiring the language to enforce that each access remains within the bounds and lifetime of the object concerned. ^[1] ^[2]

Consider:

// Allocate enough storage for n struct item objects and make p point to the first one.
struct item *p = malloc(n * sizeof *p);

The compiler can establish facts about the types involved:

p has type struct item *;
sizeof *p is the size of a struct item;
pointer arithmetic on p is scaled according to that type.

But those facts are only part of the reasoning that makes the statement meaningful. The language determines what the compiler can be required to establish, and C leaves much of the reasoning connecting values and operations to valid memory implicit.

The compiler therefore generally does not establish that:

n * sizeof *p did not overflow;
malloc succeeded;
the allocation provides enough storage for n objects;
p is being used to designate those objects;
the programmer's interpretation of n is correct;
the objects remain alive; or
a subsequent access falls within the intended object.

C's types help the compiler determine how operations on values should be translated, but they do not require it to prove the entire chain of reasoning that connects those operations to valid memory. That responsibility remains, to a significant extent, with the programmer.

Memory-safety problems arise when that reasoning ceases to hold. A value may produce the wrong allocation size; a pointer may consequently designate the wrong location; a range may extend beyond its intended object; or an object may no longer exist when it is accessed.

The central difficulty is that the programmer's model of the memory being accessed can diverge from the memory that the program actually accesses. This book seeks to make that divergence visible and to develop a way of reasoning backwards from an invalid access to the assumptions about values, objects, bounds, locations, and lifetimes that made it possible.

The memory chain

Memory-safety bugs in C are often described using categories such as:

integer overflow
buffer overflow
out-of-bounds access
use-after-free
double free
memory corruption

These categories are useful for describing failures, but they can hide the relationships between them. A vulnerability may begin as an error in one part of a program and become visible only after that error has propagated through several subsequent operations.

Consider a program that receives a count, calculates a size from that count, allocates memory, walks through the resulting object, and eventually copies data into it.

The count might be wrong.

The calculation might be wrong.

The allocation might be too small.

The pointer might be calculated from the wrong value.

The bounds might be wrong.

The copy might be too large.

The object might no longer exist.

The eventual failure may therefore occur several steps away from the original mistake.

A useful starting point for following such a failure is:

  integer arithmetic
        ↓
  allocation size
        ↓
  pointer arithmetic
        ↓
      bounds
        ↓
  memory corruption

This is not a rigid sequence. Real programs may skip steps, repeat them, or introduce other operations between them. The memory chain is a way of thinking about the dependencies that connect one operation to the next.

When a number is used to describe memory, we should ask where that number came from.

When an address is calculated, we should ask what object it is intended to identify.

When memory is allocated, we should ask what logical object the allocation is supposed to contain.

When a range is accessed, we should ask why the program believes that range is valid.

And when memory is freed, we should ask whether the pointer still identifies the intended object.

The answers to these questions form a chain of reasoning.

From code to assumptions

C code often looks deceptively local. Consider:

size = count * element_size; // Calculate the total number of bytes needed
char *p = malloc(size);      // Allocate that amount of memory
char *q = p + offset;        // Compute a new pointer
memcpy(q, src, length);      // Copy length bytes to that location

Each statement is short. The interesting question is not whether each statement looks reasonable by itself. It is whether the assumptions connecting them are true.

What does count represent?

What does size represent?

What object does p point to?

What does offset measure?

What is the relationship between length and the remaining space?

The answers to these questions turn a collection of statements into a chain of reasoning. They require us to identify the invariants that connect the operations and to treat the code as an argument that memory is being allocated and addressed correctly.

A memory-safety bug occurs when an assumption required for that reasoning no longer holds.

The Wrong Amount and the Wrong Location

Memory can be wrong in two fundamental ways: the program can access the wrong amount, or it can access the wrong location.

A program can use the correct location but the wrong amount of memory. It can use the correct amount but the wrong location. It can get both wrong.

These cases lead to different manifestations, but the underlying question is the same:

What memory did the programmer believe this operation referred to,
and what memory did it actually refer to?

That question is often more useful than simply asking which bug category applies.

Why follow the chain?

Suppose a program crashes during a copy.

The copy may be where the problem becomes visible, but it may not be where the problem began.

Perhaps an input value was converted incorrectly.

Perhaps an arithmetic calculation overflowed.

Perhaps an allocation was therefore too small.

Perhaps a later pointer calculation still used the original logical size.

Perhaps the copy finally crossed the boundary of the allocation.

Looking only at the final copy tells us what went wrong at the end of the chain. Following the chain tells us why.

That distinction matters both for debugging and for security. It determines whether we merely patch the operation that happened to fail or repair the assumption that made the failure possible.

A way of reading C

The chapters that follow use this idea as a recurring method of analysis. We will not treat integer arithmetic, allocation, pointers, bounds, and memory corruption as unrelated topics. Instead, we will follow values as they move through a program.

A value may begin as:

input

become:

count

then:

size

then:

allocation

then:

offset

then:

address

and finally:

memory access

At each stage, the program relies on an assumption about what that value means. Our task is to determine whether that assumption remains true.

This approach also explains why apparently minor C details can become security vulnerabilities. A small numerical mistake is not necessarily dangerous by itself. It becomes dangerous when the resulting value is trusted to describe memory.

The Question to Keep Asking

Throughout the book, return to one question whenever code manipulates memory:

What memory did the programmer believe this operation referred to,
and what memory did it actually refer to?

Then ask:

Which value determines it?

How was that value calculated?

Which object is involved?

What bounds apply?

What happens next?

These questions provide a way to trace an invalid access backwards through the assumptions that made it possible.

The goal is not to memorize a longer list of dangerous C constructs. It is to develop a way of seeing the relationships between numbers, objects, addresses, and memory.

Once those relationships become visible, many apparently different C memory vulnerabilities start to look like variations of the same problem:

the program believed it was operating on one region of memory,
but the calculation, address, allocation, copy, or lifetime
described another.

That is the wrong memory.

Who Is This Book For?

The Wrong Memory is for C and systems programmers, security engineers, code reviewers, students, and others interested in understanding how memory-safety failures arise.

It assumes familiarity with C, pointers, arrays, structures, and dynamic allocation, but does not require experience in vulnerability research. The book is not a catalogue of C vulnerabilities; it develops a way of reasoning about the relationships between values, objects, bounds, locations, and lifetimes that make those vulnerabilities possible.

Experienced programmers will likely recognise many of the individual rules and failure modes discussed here. The aim is to see them not as isolated problems, but as different manifestations of the same underlying reasoning.

The question at its centre is:

What did the program believe about memory, and where did that belief stop being true?

An Outline of the Book

Part I: Following the Chain

Part I mirrors the pipeline of how a program prepares to interact with memory, tracing how an abstract number transforms into a structured target:

Chapter 1 (Integer Arithmetic): Explores how ordinary integer operations become memory-safety problems through signed/unsigned mismatches, wraparound, truncation, and flawed size calculations, separating a valid number from a valid size.
Chapter 2 (Allocation Size): Examines how that math becomes an object in memory via sizeof expressions, type conversions, undersized or oversized allocations, and recognizing when the allocator itself is innocent of the underlying sizing bug.
Chapter 3 (Pointer Arithmetic and Bounds): Details how allocated memory becomes addresses and ranges through array indexing, offsets, object boundaries, one-past-the-end pointers, and why possessing a valid pointer never guarantees a valid access.
Chapter 4 (From Bug to Vulnerability): Bridges ordinary programming errors to security impacts, analyzing how out-of-bounds reads and writes, data/metadata corruption, and control-flow consequences turn incorrectness into exploitability.

Part II: The Other Side of the Boundary

Part II pivots from preparation to execution, isolating mechanical failure points by looking closely at how memory is manipulated across ranges, boundaries, and locations:

Chapter 5 (Copying the Wrong Amount): Analyzes memory-copy operations (memcpy, memmove, memset) as range operations, investigating source/destination mismatches, overlapping regions, and how innocent copies become corruption primitives.
Chapter 6 (Reading the Wrong Amount): Focuses on unauthorized consumption beyond intended boundaries, addressing length fields, sentinel/terminator assumptions, missing bounds checks, and why out-of-bounds reads are dangerous even without data overwrites.
Chapter 7 (Writing the Wrong Amount): Explores stack and heap corruption, off-by-one errors, struct/array boundary violations, metadata overwrites, and why the object containing the bug is often entirely separate from the object that gets corrupted.
Chapter 8 (Addressing the Wrong Location): Examines cases where the allocated size is correct but the destination is wrong due to incorrect offsets, pointer provenance adjustments, NULL/near-NULL addresses, and misidentified objects.

Part III: Lifetime

Part III introduces the temporal dimension, moving beyond spatial boundaries to examine how objects age, expire, and get reclaimed across time:

Chapter 9 (Using Memory After Its Lifetime): Tackles temporal safety through use-after-free conditions, dangling pointers, stale aliases, reallocation traps, and how allocator reuse alters the nature of the corruption.
Chapter 10 (Freeing the Wrong Memory): Looks at invalid lifecycle operations, including double frees, invalid frees, interior pointer releases, ownership confusion, and error paths where cleanup logic goes awry.
Chapter 11 (The Complete Memory Operation): Brings all the threads together into unified synthesis, integrating complete operational chains, the five diagnostic questions, boundary proofs, modern defenses, and debugging strategies into a final, comprehensive review.

Appendices

The six appendices extend the ideas developed in the main chapters beyond the analysis of individual C vulnerabilities. They can be read independently, but together they deepen the questions raised throughout Chapters 1–11: how memory safety can be achieved; why C fails to provide it; whether C itself can become meaningfully memory safe without ceasing to be C; and what changes in a programmer's mental model when moving from C to Rust. The fifth appendix extends these questions into AI-assisted invariant analysis, exploring how AI might help programmers discover the “unknown unknowns” — invariants that exist in code but have never been explicitly written down, documented, or enforced. The sixth appendix takes the central model developed throughout the book into language design, specifying CobaltC, a C-like systems programming language whose safety model makes memory validity, ownership, lifetime, bounds, and related invariants explicit parts of the language itself. The final seventh appendix provides a useful visual guide to ownership, borrowing, moves, lifetimes and memory safety for programmers coming from C.

Appendix I - Making Memory Safety a Property of the Language: Examines the different ways programming languages can make memory-safety guarantees explicit and enforceable, including garbage collection, bounds checking, ownership and borrowing, capabilities, contracts, formal verification, and explicit safe and unsafe boundaries.
Appendix II - A Theory of Semantic Invariants: Develops a formal model of semantic invariants and shows how it provides a common explanation for the causal relationships underlying different classes of C memory-safety vulnerabilities, from the first broken assumption to the eventual security consequence.
Appendix III - C may have reached the boundary of what its own design principles permit it to become: Examines whether the C language itself can acquire meaningful memory-safety guarantees while preserving the principles that govern its design and evolution, including simplicity, portability, compatibility, programming freedom, and C's existing programming model.
Appendix IV - The Psychological Transition From C To Rust: Examines the cognitive shift from C to Rust, focusing on how ownership, borrowing, mutation, aliasing, and lifetime change the way programmers represent and reason about program state.
Appendix V - AI and the Division of Cognitive Labour: Explores how AI can help programmers discover implicit invariants and make hidden assumptions visible.
Appendix VI - CobaltC Language Specification: Explores the design of a new statically typed, compiled, C-like systems programming language named CobaltC, designed to prevent the classes of memory errors that have been central to the model developed throughout *The Wrong Memory*.
Appendix VII - Ownership and Borrowing: A visual guide to ownership, borrowing, moves, lifetimes and memory safety for programmers coming from C.

Bibliography

Bibliography

References:

Ritchie, Dennis M., "The Development of the C Language" . Dennis Ritchie describes the development of C from BCPL and B and the design considerations that shaped its low-level systems-programming orientation, including its relationship to the PDP-11 and Unix.
The Development of the C Language

ISO/IEC 9899 — Programming Language C . The C standard specifies C's object, pointer, array, storage-duration and pointer-arithmetic semantics. These provisions establish the language's relatively direct relationship between pointers, objects and memory, while the standard's rules also define circumstances in which pointer use becomes undefined behaviour rather than imposing automatic runtime bounds or lifetime enforcement.
ISO/IEC 9899 — Programming Language C