Use After Free

Memory is freed, but a pointer to that memory (a "dangling pointer") is used again afterward without being cleared first. If an attacker can control what gets allocated into that now-reusable memory region before the dangling pointer is used, they can corrupt the program's execution state - commonly used as a primitive for remote code execution in browsers and other complex native applications, and one of the most exploited bug classes in modern memory-safety research precisely because it's subtle to spot in code review (the free and the reuse are often far apart in the source).

This is a temporal, allocator-level bug - it depends on the exact sequence and timing of memory allocation and deallocation inside a compiled process, which is entirely invisible from outside the process. There's no HTTP-observable signature for it.

Memory sanitizers (particularly AddressSanitizer's use-after-free detection) running against a fuzzed or exercised binary, and manual source review tracing every pointer's free-then-reuse lifecycle, are the standard detection paths.

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