a heap overflow

When a program needs memory whose size it only learns at run time, it asks the allocator with malloc() and gets back a chunk on the heap (the heap here is the dynamic-allocation REGION of memory, not the heap data structure / priority queue). A heap overflow is writing past the end of one of those malloc'd chunks, scribbling over whatever the allocator placed right after it — which may be another live object, or the allocator's own bookkeeping.

The mechanics depend on what sits next to the overflowed chunk. Allocators like glibc's place small control structures — chunk size fields, free-list pointers, in-use flags — physically adjacent to the data they manage, often in headers just before or after each chunk (boundary tags). If you overflow chunk A, you can corrupt the metadata of chunk B that follows it: rewrite B's recorded size, or, once B is freed, overwrite the forward/backward pointers the allocator keeps in B to thread it onto a free list. The classic exploitation then abuses free() or the next malloc(): when the allocator unlinks or relinks a chunk using attacker-controlled pointers, it can be tricked into writing an attacker-chosen value to an attacker-chosen address — turning a buffer overflow into an arbitrary write. Overwriting a neighbouring object's data or function pointer is a second, often simpler, path.

It matters because heaps hold the long-lived, interesting state of a program — objects, strings, parsed input — and overflows there bypass stack canaries entirely. The honest caveat: heap layout is far less predictable than the stack, so practical heap exploitation usually requires HEAP GROOMING (arranging allocations so the target object lands right after the overflowable one), and modern allocators add integrity checks (safe-unlinking, pointer mangling) precisely to make metadata attacks harder.