AddressSanitizer (ASan)
AddressSanitizer (ASan) is a widely adopted memory error detection tool used extensively during software testing, particularly fuzzing. It helps detect memory corruption bugs that might otherwise go unnoticed, such as buffer overflows, use-after-free errors, and other memory safety violations.
Overview
ASan is a standard practice in fuzzing due to its effectiveness in identifying memory vulnerabilities. It instruments code at compile time to track memory allocations and accesses, detecting illegal operations at runtime.
Key Concepts
When to Apply
Apply this technique when:
- Fuzzing C/C++ code for memory safety vulnerabilities
- Testing Rust code with unsafe blocks
- Debugging crashes related to memory corruption
- Running unit tests where memory errors are suspected
Skip this technique when:
- Running production code (ASan can reduce security)
- Platform is Windows or macOS (limited ASan support)
- Performance overhead is unacceptable for your use case
- Fuzzing pure safe languages without FFI (e.g., pure Go, pure Java)
Quick Reference
Step-by-Step
Step 1: Compile with ASan
Compile and link your code with the -fsanitize=address flag:
The -g flag is recommended to get better stack traces when ASan detects errors.
Step 2: Configure ASan Options
Set the ASAN_OPTIONS environment variable to configure ASan behavior:
Step 3: Run Your Program
Execute the ASan-instrumented binary. When memory errors are detected, ASan will print detailed reports:
Step 4: Adjust Fuzzer Memory Limits
ASan requires approximately 20TB of virtual memory. Disable fuzzer memory restrictions:
- libFuzzer:
-rss_limit_mb=0 - AFL++:
-m none
Common Patterns
Pattern: Basic ASan Integration
Use Case: Standard fuzzing setup with ASan
Before:
After:
Pattern: ASan with Unit Tests
Use Case: Enable ASan for unit test suite
Before:
After:
Advanced Usage
Tips and Tricks
Understanding ASan Reports
When ASan detects a memory error, it prints a detailed report including:
- Error type: Buffer overflow, use-after-free, etc.
- Stack trace: Where the error occurred
- Allocation/deallocation traces: Where memory was allocated/freed
- Memory map: Shadow memory state around the error
Example ASan report:
Combining Sanitizers
ASan can be combined with other sanitizers for comprehensive detection:
Platform-Specific Considerations
Linux: Full ASan support with best performance macOS: Limited support, some features may not work Windows: Experimental support, not recommended for production fuzzing
Anti-Patterns
Tool-Specific Guidance
libFuzzer
Compile with both fuzzer and address sanitizer:
Run with unlimited RSS:
Integration tips:
- Always combine
-fsanitize=fuzzerwith-fsanitize=address - Use
-gfor detailed stack traces in crash reports - Consider
ASAN_OPTIONS=abort_on_error=1for better crash handling
See: libFuzzer: AddressSanitizer
AFL++
Use the AFL_USE_ASAN environment variable:
Run with unlimited memory:
Integration tips:
AFL_USE_ASAN=1automatically adds proper compilation flags- Use
-m noneto disable AFL++'s memory limit - Consider
AFL_MAP_SIZEfor programs with large coverage maps
cargo-fuzz (Rust)
Use the --sanitizer=address flag:
Or configure in fuzz/Cargo.toml:
Integration tips:
- ASan is useful for fuzzing unsafe Rust code or FFI boundaries
- Safe Rust code may not benefit as much (compiler already prevents many errors)
- Focus on unsafe blocks, raw pointers, and C library bindings
See: cargo-fuzz: AddressSanitizer
honggfuzz
Compile with ASan and link with honggfuzz:
Compile the target:
Integration tips:
- honggfuzz works well with ASan out of the box
- Use feedback-driven mode for better coverage with sanitizers
- Monitor memory usage, as ASan increases memory footprint
Troubleshooting
Related Skills
Tools That Use This Technique
Related Techniques
Resources
Key External Resources
AddressSanitizer on Google Sanitizers Wiki
The official ASan documentation covers:
- Algorithm and implementation details
- Complete list of detected error types
- Performance characteristics and overhead
- Platform-specific behavior
- Known limitations and incompatibilities
Common configuration flags shared across all sanitizers:
verbosity: Control diagnostic output levellog_path: Redirect sanitizer output to filessymbolize: Enable/disable symbol resolution in reportsexternal_symbolizer_path: Use custom symbolizer
ASan-specific configuration options:
detect_leaks: Control memory leak detectionabort_on_error: Callabort()vs_exit()on errordetect_stack_use_after_return: Detect stack use-after-return bugscheck_initialization_order: Find initialization order bugs
Common pitfalls and solutions:
- Linking order issues
- Conflicts with other tools
- Platform-specific problems
- Performance tuning tips
Clang AddressSanitizer Documentation
Clang-specific guidance:
- Compilation flags and options
- Interaction with other Clang features
- Supported platforms and architectures
GCC-specific ASan documentation:
- GCC-specific flags and behavior
- Differences from Clang implementation
- Platform support in GCC
AddressSanitizer: A Fast Address Sanity Checker (USENIX Paper)
Original research paper with technical details:
- Shadow memory algorithm
- Virtual memory requirements (historically 16TB, now ~20TB)
- Performance benchmarks
- Design decisions and tradeoffs

