Free of Memory not on the Heap

Code calls a heap-deallocation function (like free()) on a pointer that doesn't actually point to heap-allocated memory - a stack address, a statically allocated variable, or memory from a different allocator entirely. Heap allocators expect their own bookkeeping metadata to precede any block they're asked to free; calling free on non-heap memory corrupts whatever data structure the allocator finds there instead, similar in effect to other memory-corruption primitives.

This is a specific native-code allocator-misuse pattern, only observable by inspecting the actual pointer sources feeding deallocation calls in compiled code - invisible from outside the process.

Memory-sanitizer-backed fuzzing and static/manual review tracing the origin of every pointer passed to a free/deallocation call.

Tip: These bugs are notoriously execution-order-dependent, so static code review alone under-catches them — a sanitizer-backed fuzzer that actually exercises the specific free-then-use sequence at runtime is where this class is reliably found.

Real-World Impact

Use-after-free and double-free bugs exploit a gap between when memory is freed and when the program stops using the pointer to it — the memory can be reallocated for something else entirely by the time the stale pointer is dereferenced again, so the operation ends up reading or writing through what the program still thinks is the original object but is now attacker-influenceable heap content. This is one of the more consistently exploitable memory-safety patterns in modern browsers and native applications specifically because heap allocators are predictable enough that an attacker can often arrange for the freed memory to be reclaimed by something they control.

Null pointer dereferences and type confusion are the less catastrophic but far more common siblings: a null dereference is usually "only" a crash (denial of service), while type confusion, treating a block of memory as one type when it was actually allocated as another, can leak data or corrupt state depending on how the two types' memory layouts differ.

Across this family, the severity ceiling is remote code execution, and it's a recurring theme in disclosed reports against parsers, media codecs, and any component that manages object lifetimes across a complex call graph — the more paths there are to free an object, the more places there are for one of them to be missed.

Prevention and Secure Design

Preventing Free of Memory not on the Heap takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Prefer a memory-safe language or smart-pointer discipline. Rust's ownership model eliminates use-after-free by construction; in C++, consistent use of smart pointers (unique_ptr/shared_ptr) over raw pointers closes off most of the common patterns that lead here.

Null out pointers immediately after freeing them. A freed-then-nulled pointer turns a potential use-after-free into an immediate, safe null dereference instead of a silent, exploitable one — a small habit with an outsized effect.

Fuzz with a memory sanitizer, specifically one that tracks object lifetime. AddressSanitizer's use-after-free detection catches this class reliably in a way static review often misses, since the bug only manifests on a specific execution order.

Audit every path that can free an object. Use-after-free bugs concentrate in code with multiple cleanup paths (error handling, early returns, exception paths) — review those specifically for a free that isn't matched by the same discipline as the main path.

Validate type before reinterpreting memory. Where polymorphic or type-punned data is unavoidable, check a type tag before treating a block of memory as a specific type, rather than trusting the caller.