Project 6: A Basic C-Based Custom Allocator (malloc Clone)

Technical Objective

Isolates and tests manual heap management — replacing libc's malloc/free with a custom allocator built directly on the sbrk() system call.

Business Impact Summary: Memory corruption and heap-exploitation vulnerabilities (use-after-free, double-free, heap overflow) are among the most common root causes of critical CVEs in production software. Understanding how the allocator itself tracks and hands out memory is what lets an analyst recognize, reproduce, and explain these bug classes instead of treating them as a black box.

The "Why": Engineering Value & Threat Impact

• Operational Risk / Threat Model: Explains the mechanics behind an entire class of memory-corruption exploits (heap overflows, use-after-free, double-free) by exposing exactly how allocated and free memory are tracked and reused.
• Engineering Mastery: Proves working control over raw virtual memory allocation, pointer arithmetic, and manual metadata tracking without relying on the standard library's malloc/free.
• Defensive Utility: Gives detection and incident-response teams a concrete mental model of heap layout, useful when reading crash dumps, heap-spray artifacts, or memory-corruption CVE writeups.

Architecture & System Boundary

• Language & Toolchain: C / GCC (-std=c11 -Wall -Wextra -Werror)
• Operating System Focus: Linux x86_64, POSIX heap/virtual memory syscalls
• Core APIs/Primitives Used: sbrk(), manual pointer arithmetic over a singly linked block-header list

Technical Execution (What & How)

• Block header & free list: Every allocation is prefixed with a header (size, free flag, next pointer). Because sbrk() only ever grows the heap upward, these headers naturally stay in ascending-address order — that ordered list is the free list tracker, with no separate structure needed.
• First-fit allocation with splitting: my_malloc() scans the header list for the first free block large enough, splitting off any leftover space (above a minimum useful size) into its own free block rather than handing over more than requested.
• Coalescing trade-off: my_free() merges a freed block forward into its immediate neighbor if that neighbor is also free. This is a deliberate simplification — a singly linked list can't cheaply merge backward, so merge order depends on free order (documented in code comments), rather than adding a doubly linked list to handle every case.

How to Build & Run Locally

make test

This compiles src/allocator.c and src/test_allocator.c with -Wall -Wextra -Werror -std=c11, then runs an assertion-based suite covering allocation correctness, free-list reuse, splitting, and coalescing.