address-sanitizer
Install this skill
npx skills add trailofbits/skillsWorks across Claude Code, Cursor, Codex, Copilot & Antigravity
AddressSanitizer (ASan) is a fast memory error detector for C and C++ programs. By instrumenting code at compile time, it tracks memory accesses via shadow memory to identify bugs that typically lead to crashes or security exploits. When the application performs an invalid operation, such as accessing memory outside of buffer boundaries or referencing deallocated pointers, ASan immediately intercepts the action and provides a detailed crash report. This report includes the exact error type, the stack trace of the faulty operation, and history regarding the original memory allocation. While it imposes a noticeable performance penalty and requires significant virtual memory, it is the industry standard for identifying memory corruption vulnerabilities during fuzzing campaigns and integration testing cycles.
When to Use This Skill
- •Fuzzing C/C++ applications to uncover hidden memory vulnerabilities
- •Debugging non-deterministic segmentation faults in complex codebases
- •Validating memory safety within Rust projects that rely on unsafe blocks
- •Improving the quality of unit tests by catching subtle buffer boundary violations
How to Invoke This Skill
Example prompts that trigger this skill in Claude Code, Cursor, or Antigravity:
- “How do I find buffer overflows in my C code?
- “Set up ASan for my fuzzing workflow
- “My C++ program is crashing with random memory errors
- “How to enable memory sanitizers in Clang
- “Debug a use-after-free error
Pro Tips
- 💡Combine ASan with other sanitizers like UndefinedBehaviorSanitizer (UBSan) for a more comprehensive suite of error detections.
- 💡Utilize ASan primarily in development and testing environments due to its performance overhead, which can be 2-4x slower than uninstrumented code.
- 💡Leverage `ASAN_OPTIONS` environment variables to fine-tune runtime behavior, such as suppressing known issues or customizing error reporting.
What this skill does
- •Identifies heap, stack, and global buffer overflows
- •Detects use-after-free and use-after-scope errors
- •Tracks double-free and invalid-free memory operations
- •Identifies memory leaks during program termination
- •Provides precise stack traces mapping back to source code lines
When not to use it
- ✕Deploying code in production environments due to security and performance overhead
- ✕Environments with restricted virtual address spaces where 20TB mapping is unavailable
Example workflow
- Add -fsanitize=address and -g to your compilation flags
- Recompile the target application with instrumentation
- Set ASAN_OPTIONS environment variables to control reporting behavior
- Disable fuzzer memory limits like -rss_limit_mb=0 to prevent premature termination
- Run the binary and pipe output to a log file
- Analyze the generated report to locate the specific line of code causing the corruption
Prerequisites
- –Clang or GCC compiler with sanitization support
- –Access to build configuration (Makefiles, CMake, etc.)
- –Debug symbols (-g flag) for accurate reporting
Pitfalls & limitations
- !The 20TB virtual memory mapping can cause process failure on systems with strict memory limits
- !Performance slowdowns of 2x-4x can break timing-dependent tests
- !ASan may conflict with other custom memory allocators
- !It does not catch all logical memory bugs, only specific types of corruption
FAQ
How it compares
Manual memory debugging with GDB requires you to reproduce the crash and manually inspect state; ASan automates the detection and provides a diagnostic report the moment an illegal access occurs.
📄 Full skill instructions — original source: trailofbits/skills
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
| Concept | Description |
|---------|-------------|
| Instrumentation | ASan adds runtime checks to memory operations during compilation |
| Shadow Memory | Maps 20TB of virtual memory to track allocation state |
| Performance Cost | Approximately 2-4x slowdown compared to non-instrumented code |
| Detection Scope | Finds buffer overflows, use-after-free, double-free, and memory leaks |
## 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
| Task | Command/Pattern |
|------|-----------------|
| Enable ASan (Clang/GCC) |
-fsanitize=address || Enable verbosity |
ASAN_OPTIONS=verbosity=1 || Disable leak detection |
ASAN_OPTIONS=detect_leaks=0 || Force abort on error |
ASAN_OPTIONS=abort_on_error=1 || Multiple options |
ASAN_OPTIONS=verbosity=1:abort_on_error=1 |## Step-by-Step
### Step 1: Compile with ASan
Compile and link your code with the
-fsanitize=address flag:clang -fsanitize=address -g -o my_program my_program.cThe
-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:export ASAN_OPTIONS=verbosity=1:abort_on_error=1:detect_leaks=0### Step 3: Run Your Program
Execute the ASan-instrumented binary. When memory errors are detected, ASan will print detailed reports:
./my_program### 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:**
clang -o fuzz_target fuzz_target.c
./fuzz_target**After:**
clang -fsanitize=address -g -o fuzz_target fuzz_target.c
ASAN_OPTIONS=verbosity=1:abort_on_error=1 ./fuzz_target### Pattern: ASan with Unit Tests
**Use Case:** Enable ASan for unit test suite
**Before:**
gcc -o test_suite test_suite.c -lcheck
./test_suite**After:**
gcc -fsanitize=address -g -o test_suite test_suite.c -lcheck
ASAN_OPTIONS=detect_leaks=1 ./test_suite## Advanced Usage
### Tips and Tricks
| Tip | Why It Helps |
|-----|--------------|
| Use
-g flag | Provides detailed stack traces for debugging || Set
verbosity=1 | Confirms ASan is enabled before program starts || Disable leaks during fuzzing | Leak detection doesn't cause immediate crashes, clutters output |
| Enable
abort_on_error=1 | Some fuzzers require abort() instead of _exit() |### 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:
==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000eff4 at pc 0x00000048e6a3
READ of size 4 at 0x60300000eff4 thread T0
#0 0x48e6a2 in main /path/to/file.c:42### Combining Sanitizers
ASan can be combined with other sanitizers for comprehensive detection:
clang -fsanitize=address,undefined -g -o fuzz_target fuzz_target.c### 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
| Anti-Pattern | Problem | Correct Approach |
|--------------|---------|------------------|
| Using ASan in production | Can make applications less secure | Use ASan only for testing |
| Not disabling memory limits | Fuzzer may kill process due to 20TB virtual memory | Set
-rss_limit_mb=0 or -m none || Ignoring leak reports | Memory leaks indicate resource management issues | Review leak reports at end of fuzzing campaign |
## Tool-Specific Guidance
### libFuzzer
Compile with both fuzzer and address sanitizer:
clang++ -fsanitize=fuzzer,address -g harness.cc -o fuzzRun with unlimited RSS:
./fuzz -rss_limit_mb=0**Integration tips:**
- Always combine
-fsanitize=fuzzer with -fsanitize=address- Use
-g for detailed stack traces in crash reports- Consider
ASAN_OPTIONS=abort_on_error=1 for better crash handlingSee: [libFuzzer: AddressSanitizer](https://github.com/google/fuzzing/blob/master/docs/good-fuzz-target.md#memory-error-detection)
### AFL++
Use the
AFL_USE_ASAN environment variable:AFL_USE_ASAN=1 afl-clang-fast++ -g harness.cc -o fuzzRun with unlimited memory:
afl-fuzz -m none -i input_dir -o output_dir ./fuzz**Integration tips:**
-
AFL_USE_ASAN=1 automatically adds proper compilation flags- Use
-m none to disable AFL++'s memory limit- Consider
AFL_MAP_SIZE for programs with large coverage mapsSee: [AFL++: AddressSanitizer](https://github.com/AFLplusplus/AFLplusplus/blob/stable/docs/fuzzing_in_depth.md#a-using-sanitizers)
### cargo-fuzz (Rust)
Use the
--sanitizer=address flag:cargo fuzz run fuzz_target --sanitizer=addressOr configure in
fuzz/Cargo.toml:[profile.release]
opt-level = 3
debug = true**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](https://rust-fuzz.github.io/book/cargo-fuzz/tutorial.html#sanitizers)
### honggfuzz
Compile with ASan and link with honggfuzz:
honggfuzz -i input_dir -o output_dir -- ./fuzz_target_asanCompile the target:
hfuzz-clang -fsanitize=address -g target.c -o fuzz_target_asan**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
| Issue | Cause | Solution |
|-------|-------|----------|
| Fuzzer kills process immediately | Memory limit too low for ASan's 20TB virtual memory | Use
-rss_limit_mb=0 (libFuzzer) or -m none (AFL++) || "ASan runtime not initialized" | Wrong linking order or missing runtime | Ensure
-fsanitize=address used in both compile and link || Leak reports clutter output | LeakSanitizer enabled by default | Set
ASAN_OPTIONS=detect_leaks=0 || Poor performance (>4x slowdown) | Debug mode or unoptimized build | Compile with
-O2 or -O3 alongside -fsanitize=address || ASan not detecting obvious bugs | Binary not instrumented | Check with
ASAN_OPTIONS=verbosity=1 that ASan prints startup info || False positives | Interceptor conflicts | Check ASan FAQ for known issues with specific libraries |
## Related Skills
### Tools That Use This Technique
| Skill | How It Applies |
|-------|----------------|
| **libfuzzer** | Compile with
-fsanitize=fuzzer,address for integrated fuzzing with memory error detection || **aflpp** | Use
AFL_USE_ASAN=1 environment variable during compilation || **cargo-fuzz** | Use
--sanitizer=address flag to enable ASan for Rust fuzz targets || **honggfuzz** | Compile target with
-fsanitize=address for ASan-instrumented fuzzing |### Related Techniques
| Skill | Relationship |
|-------|--------------|
| **undefined-behavior-sanitizer** | Often used together with ASan for comprehensive bug detection (undefined behavior + memory errors) |
| **fuzz-harness-writing** | Harnesses must be designed to handle ASan-detected crashes and avoid false positives |
| **coverage-analysis** | Coverage-guided fuzzing helps trigger code paths where ASan can detect memory errors |
## Resources
### Key External Resources
**[AddressSanitizer on Google Sanitizers Wiki](https://github.com/google/sanitizers/wiki/AddressSanitizer)**
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
**[SanitizerCommonFlags](https://github.com/google/sanitizers/wiki/SanitizerCommonFlags)**
Common configuration flags shared across all sanitizers:
-
verbosity: Control diagnostic output level-
log_path: Redirect sanitizer output to files-
symbolize: Enable/disable symbol resolution in reports-
external_symbolizer_path: Use custom symbolizer**[AddressSanitizerFlags](https://github.com/google/sanitizers/wiki/AddressSanizerFlags)**
ASan-specific configuration options:
-
detect_leaks: Control memory leak detection-
abort_on_error: Call abort() vs _exit() on error-
detect_stack_use_after_return: Detect stack use-after-return bugs-
check_initialization_order: Find initialization order bugs**[AddressSanitizer FAQ](https://github.com/google/sanitizers/wiki/AddressSanitizer#faq)**
Common pitfalls and solutions:
- Linking order issues
- Conflicts with other tools
- Platform-specific problems
- Performance tuning tips
**[Clang AddressSanitizer Documentation](https://clang.llvm.org/docs/AddressSanitizer.html)**
Clang-specific guidance:
- Compilation flags and options
- Interaction with other Clang features
- Supported platforms and architectures
**[GCC Instrumentation Options](https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fsanitize_003daddress)**
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)](https://www.usenix.org/sites/default/files/conference/protected-files/serebryany_atc12_slides.pdf)**
Original research paper with technical details:
- Shadow memory algorithm
- Virtual memory requirements (historically 16TB, now ~20TB)
- Performance benchmarks
- Design decisions and tradeoffs
How to Use This Skill Unit
Option A: Project-Specific (Recommended)
- Click "Download" above
- In your project, create the directory:
.agent/skills/address-sanitizer/ - Save the file as
SKILL.md - The agent will automatically discover the skill based on its description.
Option B: Global Installation (All Agents)
Save the file to these locations to make it available across all projects:
- Claude Code:
~/.claude/skills/trailofbits/skills/address-sanitizer/SKILL.md - Cursor:
~/.cursor/skills/trailofbits/skills/address-sanitizer/SKILL.md - Antigravity:
~/.gemini/antigravity/skills/trailofbits/skills/address-sanitizer/SKILL.md
🚀 Install with CLI:npx skills add trailofbits/skills