Detecting Memory Safety Bugs

Detecting memory-safety bugs

Temporal and spatial memory bugs are the ones a sink-based catalog usually doesn't model: there's no single "dangerous function" to grep - the bug is a relationship between a pointer's lifetime and its use, or between an index and a bound, spread across code paths. So you hunt them by reasoning about lifetime and bounds, not by matching a call. This skill covers the five workhorse classes and how to confirm each.

When to use

• The target is C/C++/Rust-unsafe/CGo or any unmanaged memory, and you want the classes a catalog leaves out (hunting-bugs-with-a-code-graph flags these as out-of-catalog and sends you here).
• You're reviewing allocators, parsers, serializers, ring buffers, refcounting, or anything doing pointer arithmetic.

Scope check

Authorized source only. If you can't name the authorization, stop.

The five classes and how to confirm each

For every candidate, the confirmation is a path: an allocation/definition site, the operation that changes its state, and the use - read the source at each.

1. Use-after-free (UAF). A pointer is used after its object is freed. Hunt: for each free/delete/refcount-drop, ask what still holds this pointer and can any path reach a use after this point - including aliases stored in structs, callbacks, and error paths. Confirm: a live path free → … → deref with no reassignment in between. Watch the classic shapes: free-in-a-loop then use, free in an error branch then fallthrough use, and a cached pointer that outlives the object.

2. Double-free. The same allocation freed twice. Hunt: two frees reachable in sequence on some path without a nulling/reassignment between them; ownership handed to a callee that also frees; error paths that free then fall into a cleanup that frees again. Confirm: both frees hit the same object on one path.

3. Out-of-bounds read/write. An index or pointer crosses a buffer's bound. Hunt: every buffer access where the index/length is attacker-influenced or derived from a separate field (length prefixes are a hotspot). Confirm: trace the index/length source and the buffer's true size; the bug is any path where index/len can exceed size - off-by-one at <= size, unchecked memcpy length, integer-truncated length, signed/unsigned confusion at the check.

4. Uninitialized use. A value is read before it's written. Hunt: stack structs and locals used on a path that skipped their initialization (an early goto, an error branch, a partially-filled struct). Confirm: a path from declaration to use with no write on that path.

5. NULL / invalid-pointer deref. A pointer that can be NULL (or an error sentinel) is dereferenced without a check. Hunt: allocation and lookup returns that can fail; dereferences of a parameter documented as nullable. Confirm: a path where the returning call can yield NULL and the deref has no guard between.

Integer overflow feeds all of the above

Overflow is rarely the final bug - it's the step that produces a bad length/index/size. Treat a * b, a + b, and truncating casts on attacker-influenced sizes as candidates because they flow into an allocation or a bound. Trace overflow → size/index → memory op; report the memory bug with the overflow as its cause.

Worked example

UAF via error path. In parse_record: rec = alloc(); if (read(rec) < 0) { free(rec); } … use(rec->field); - the free is in the error branch but the function falls through to use(rec->field) without returning. Path: alloc → free (error branch) → deref (fallthrough). Confirmed UAF; reachable = conditional (read returns < 0); impact = attacker-triggered malformed record frees then dereferences. Remediation: return after the free, or restructure cleanup with a single exit.

Rationalizations to reject

• "There's no dangerous function call, so it's memory-safe." → These classes have no single sink. Reason about lifetime and bounds, not calls.
• "The length is checked." → Checked where, against the true size, before every path to the access, and without integer truncation? Verify all four.
• "It's freed once in the code I can see." → Ownership may free again in a callee or a cleanup path. Follow the pointer, including aliases.
• "The compiler/sanitizer would catch it." → Only on inputs the test suite exercised. Static path reasoning finds the untested path.

Executing this in practice

You need to follow a pointer's aliases and a value's flow across functions, and read the exact body at each site. A code property graph with points-to/alias information makes "what else holds this pointer" answerable; a memory-safety static analyzer (or the compiler's sanitizers on targeted inputs) corroborates; manual path reading closes it. Confirm every class as a concrete path, then emit per the finding schema with the alloc/free/use hops in path.

Related

• adjudicating-taint-paths - for the attacker-input side (who controls the length/index).
• hunting-bugs-with-a-code-graph - the master loop that routes these here.
• FINDING-SCHEMA.md.