NULL Pointer Dereference

Code attempts to read or write through a pointer that's currently null (uninitialized, or the result of a failed lookup/allocation that wasn't checked), which in most environments causes an immediate crash. On its own this is usually a denial-of-service bug - one malformed input reliably crashing the process - though in some memory-unsafe contexts a null-pointer dereference can be a stepping stone to a more serious memory-corruption primitive depending on what's mapped at address zero.

Whether a given code path ever dereferences an unchecked null pointer is a source-level or runtime-crash observation - an HTTP scan sees only that a request either got a response or didn't, with no visibility into why a crash happened at the process level.

Static analysis (most modern compilers and linters flag many null-deref paths directly), fuzzing, and crash-report triage from actual production crashes.

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 NULL Pointer Dereference 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.