AddressSanitizer

AddressSanitizer (commonly abbreviated ASan or Asan) is a compiler- and runtime-based instrumentation tool for detecting memory-access errors, most notably buffer overruns and other out-of-bounds memory operations. It works by instrumenting a program (typically at compile time) so that each memory access is checked against a shadow-memory layout, causing the program to abort with a diagnostic when an invalid access is detected. Because of its precise, instrumentation-based approach, AddressSanitizer does not rely on conservative static analyses such as points-to analysis, and it is widely used both as a bug-finding aid in normal builds and as an oracle for fuzz-testing campaigns [HDR-Fuzz, SpecFuzz, Bottom-Up Generation of Verilog Designs for Testing EDA Tools].

Role in bug detection and fuzzing

Buffer-overrun fuzzing guidance (HDR-Fuzz)

HDR-Fuzz proposes a new approach for detecting buffer-overrun vulnerabilities that combines greybox fuzzing with AddressSanitizer. Earlier buffer-overrun fuzzing work relied on a metric called headroom, which required a conservative points-to analysis and was therefore imprecise and expensive. HDR-Fuzz instead uses an extended version of ASan running in parallel with the fuzzer. The extended ASan reports back to the fuzzer those test inputs that come closer to exposing buffer-overrun vulnerabilities. Because ASan's instrumentation is precise and does not depend on points-to analysis, HDR-Fuzz is presented as a ground-up redesign that retains the benefits of guided fuzzing without the imprecision of purely static approaches [HDR-Fuzz].

Speculative-execution vulnerability testing (SpecFuzz)

SpecFuzz uses AddressSanitizer as the integrity checker under a technique called speculation exposure. The program is instrumented so that code paths reachable only via speculative execution (for example, due to branch mispredictions) are force-executed in software, making speculative memory accesses visible to AddressSanitizer. Combined with conventional fuzzing, this enables dynamic, runtime-based identification of speculative-execution vulnerabilities such as Spectre V1, which static analyzers tend to miss or over-approximate. The SpecFuzz prototype was reported to detect all known variations of Spectre V1 and to reduce the number of instrumented branches by up to 77% in evaluated applications, thereby lowering mitigation overhead [SpecFuzz].

Use as a compile-time sanitizer in empirical studies

AddressSanitizer is also used as a standard, off-the-shelf sanitizer when empirically comparing fuzzers on real tools. In a study of Verilog-generation fuzzers, the authors compiled each target tool (Verible's obfuscator, Yosys, and Verilator) both with and without ASan to count crashes produced by randomly generated designs. With ASan enabled, the generator ChiGen revealed 754 crashes in Yosys (vs. 747 from Verismith and VlogHammer, and 742 from TransFuzz), 52 in Verilator (vs. 1 from Verismith and VlogHammer, and none from TransFuzz), and 766 in Verible's obfuscator (peak 771 from Verismith). Without ASan, the same input population produced substantially fewer detected crashes, for example 47 crashes in Verilator for ChiGen versus 1 for Verismith and VlogHammer. The study explicitly notes that ASan produces large volumes of crash logs whose individual inspection was infeasible, so crashes are counted rather than deduplicated by root cause [Bottom-Up Generation of Verilog Designs for Testing EDA Tools].

The related fuzzer ChiGen is known to be instrumented against target tools using AddressSanitizer when running bug-finding campaigns on open-source EDA tooling, so that memory-safety violations produced by malformed Verilog are surfaced rather than silently corrupting state.