Generated banner for Address Sanitizer
Generated logo for Address Sanitizer

Address Sanitizer

Trail of BitsOfficialPublished by Trail of Bits

  • Skill
  • Tool integration
  • Software development
  • CC-BY-SA-4.0
  • No issues found

From the author

Builds and runs code under AddressSanitizer to catch buffer overflows, use-after-free, and other memory errors during fuzzing or tests. Covers -fsanitize=address builds, ASAN_OPTIONS, reading the crash report, LeakSanitizer, and the overhead and platform trade-offs. Use when fuzzing C/C++ or Rust that has unsafe blocks or FFI, when debugging a memory corruption crash, or when reading an ASan stack trace.
— the description by Trail of Bits

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

AddressSanitizer (ASan) is a powerful memory error detector for C, C++, and Rust. By instrumenting code at compile time, it tracks memory allocations and accesses to identify illegal operations at runtime. It is a standard tool for fuzzing and testing, providing detailed reports on memory safety violations, including heap-buffer-overflows and memory leaks. While highly effective, it introduces performance overhead and requires specific configuration for fuzzer memory limits.

What it does

  • Instruments code at compile time to monitor memory operations.
  • Detects buffer overflows, use-after-free, double-free, and memory leaks.
  • Provides detailed stack traces and allocation history for detected errors.
  • Supports configuration via ASAN_OPTIONS for custom runtime behavior.
  • Integrates with major fuzzers like libFuzzer, AFL++, and cargo-fuzz.
  • Allows combining with other sanitizers for comprehensive bug detection.

When to use it

  • When fuzzing C/C++ code to identify memory vulnerabilities.
  • When testing Rust code that utilizes unsafe blocks or FFI.
  • When debugging crashes suspected of being caused by memory corruption.
  • When running unit tests to ensure memory safety.

Advantages

  • Highly effective at catching elusive memory corruption bugs.
  • Provides actionable reports with clear stack traces.
  • Seamless integration with popular build systems and fuzzers.
  • Configurable runtime options to suit different testing needs.

Usage examples

“How do I compile my C program with AddressSanitizer?”
Use the -fsanitize=address flag during compilation and linking, ideally with the -g flag to ensure detailed stack traces are generated in reports.
“My fuzzer crashes immediately when using ASan, what is wrong?”
ASan requires significant virtual memory. You must disable fuzzer memory limits, such as using -rss_limit_mb=0 for libFuzzer or -m none for AFL++.
“How can I configure ASan to abort on error?”
Set the environment variable ASAN_OPTIONS=abort_on_error=1 before executing your instrumented binary.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/trailofbits/address-sanitizer/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip address-sanitizer.zip -d .agents/skills

Documentation by Trail of Bits

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
ConceptDescription
InstrumentationASan adds runtime checks to memory operations during compilation
Shadow MemoryMaps 20TB of virtual memory to track allocation state
Performance CostApproximately 2-4x slowdown compared to non-instrumented code
Detection ScopeFinds 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

TaskCommand/Pattern
Enable ASan (Clang/GCC)-fsanitize=address
Enable verbosityASAN_OPTIONS=verbosity=1
Disable leak detectionASAN_OPTIONS=detect_leaks=0
Force abort on errorASAN_OPTIONS=abort_on_error=1
Multiple optionsASAN_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.c

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:

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
TipWhy It Helps
Use -g flagProvides detailed stack traces for debugging
Set verbosity=1Confirms ASan is enabled before program starts
Disable leaks during fuzzingLeak detection doesn't cause immediate crashes, clutters output
Enable abort_on_error=1Some 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-PatternProblemCorrect Approach
Using ASan in productionCan make applications less secureUse ASan only for testing
Not disabling memory limitsFuzzer may kill process due to 20TB virtual memorySet -rss_limit_mb=0 or -m none
Ignoring leak reportsMemory leaks indicate resource management issuesReview 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 fuzz

Run 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 handling

See: libFuzzer: AddressSanitizer

AFL++

Use the AFL_USE_ASAN environment variable:

AFL_USE_ASAN=1 afl-clang-fast++ -g harness.cc -o fuzz

Run 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 maps

See: AFL++: AddressSanitizer

cargo-fuzz (Rust)

Use the --sanitizer=address flag:

cargo fuzz run fuzz_target --sanitizer=address

Or 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

honggfuzz

Compile with ASan and link with honggfuzz:

honggfuzz -i input_dir -o output_dir -- ./fuzz_target_asan

Compile 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

IssueCauseSolution
Fuzzer kills process immediatelyMemory limit too low for ASan's 20TB virtual memoryUse -rss_limit_mb=0 (libFuzzer) or -m none (AFL++)
"ASan runtime not initialized"Wrong linking order or missing runtimeEnsure -fsanitize=address used in both compile and link
Leak reports clutter outputLeakSanitizer enabled by defaultSet ASAN_OPTIONS=detect_leaks=0
Poor performance (>4x slowdown)Debug mode or unoptimized buildCompile with -O2 or -O3 alongside -fsanitize=address
ASan not detecting obvious bugsBinary not instrumentedCheck with ASAN_OPTIONS=verbosity=1 that ASan prints startup info
False positivesInterceptor conflictsCheck ASan FAQ for known issues with specific libraries
Tools That Use This Technique
SkillHow It Applies
libfuzzerCompile with -fsanitize=fuzzer,address for integrated fuzzing with memory error detection
aflppUse AFL_USE_ASAN=1 environment variable during compilation
cargo-fuzzUse --sanitizer=address flag to enable ASan for Rust fuzz targets
honggfuzzCompile target with -fsanitize=address for ASan-instrumented fuzzing
SkillRelationship
undefined-behavior-sanitizerOften used together with ASan for comprehensive bug detection (undefined behavior + memory errors)
fuzz-harness-writingHarnesses must be designed to handle ASan-detected crashes and avoid false positives
coverage-analysisCoverage-guided fuzzing helps trigger code paths where ASan can detect memory errors

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

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

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

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 Instrumentation Options

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

Files

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Trail of Bits
Publisher
Trail of Bits (Official)
Source
trailofbits/skills · plugins/testing-handbook-skills/skills/address-sanitizer · commit e4dd0bb
Licence
Creative Commons Attribution-ShareAlike 4.0 International (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Trail of Bits.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download address-sanitizer.zip