Double Free

The same allocated memory block is freed more than once. Heap allocators aren't designed to handle a second free() call on already-released memory gracefully - the second call can corrupt the allocator's internal free-list bookkeeping, which an attacker who controls timing and allocation patterns can sometimes turn into a write-what-where primitive and, from there, arbitrary code execution. It's closely related to use-after-free (both stem from incorrect memory-lifetime tracking) but is specifically about the deallocation call itself happening twice rather than a stale pointer being read or written after a single free.

This is an allocator-internal bug only observable by tracking a compiled process's actual memory-management calls - invisible from an HTTP request/response exchange.

Memory sanitizers (AddressSanitizer's double-free detection) running against fuzzed or exercised binaries, and manual review of every code path that frees a given pointer, checking whether more than one of them can run against the same allocation.

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