Find Memory Bugs with AddressSanitizer

Topic Overview

AddressSanitizer (ASan)

AddressSanitizer is a fast memory error detector for C/C++ built into GCC and Clang. It instruments memory accesses at compile time to catch buffer overflows, use-after-free, and other memory bugs with roughly 2x slowdown (much faster than Valgrind).

How ASan Works

ASan adds redzones (poisoned memory) around every allocation and maintains a shadow memory map:

• Every 8 bytes of application memory maps to 1 shadow byte
• Shadow value 0 means all 8 bytes are accessible
• Negative shadow values mark redzones as inaccessible

Compile with:

cCopy
Loading…

ASan detects stack-buffer-overflow, heap-buffer-overflow, use-after-free, and global-buffer-overflow with detailed stack traces showing the exact source line.

For This Exercise

You will compute the shadow-memory layout for a heap allocation and grade a memory access against it, byte exactly like ASan does: full 8-byte granules shadow as 00, the tail granule of a non-multiple-of-8 allocation shadows as the number of accessible bytes (01-07), and the heap right redzone shadows as 0xfb. Given an access offset, you decide whether it is addressable or poisoned: the exact arithmetic behind every heap-buffer-overflow report.

Running ASan in CI

Combine -fsanitize=address with -g for source-line stack traces. Set ASAN_OPTIONS=detect_leaks=1 to catch memory leaks alongside overflow detection. ASan adds roughly 2x runtime overhead, making it practical for test suites but not production deployment. Pair ASan with fuzzing (libFuzzer, AFL) to find bugs that only trigger on specific inputs. MSan covers uninitialized reads that ASan misses.

Write a C program that computes an ASan shadow-memory layout and grades an access against it.

Requirements:

• Read an allocation size (bytes) and an access offset (0-based) from stdin
• Derive the shadow layout: one shadow byte per 8 application bytes; full granules are 00; if the size is not a multiple of 8, the tail granule shadows as size % 8 (01-07); the first right-redzone granule is 0xfb (heap right redzone magic)
• Map the access offset to its granule and in-granule position, read the shadow value, and apply ASan's rule: a partial shadow value k makes only the first k bytes of the granule addressable
• Verdict: OK, heap-buffer-overflow (partial-granule redzone), or heap-buffer-overflow (right redzone)

Success Criteria:

• The shadow dump is computed from the allocation size, including the 01-07 partial granule
• Accesses inside the partial granule's accessible prefix are OK; past it they are poisoned
• Accesses past the allocation land in the fb redzone