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...