AddressSanitizer: A Fast Address Sanity Checker

By Kostya Serebryany, Derek Bruening, Alexander Potapenko, Dmitriy Vyukov. 2012

1,300 citations recorded by the source corpus.

Subfields: Program Analysis & Verification, Software Engineering

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

In Program Analysis & Verification

In Software Engineering

Citations in the corpus

Lost at C: A User Study on the Security Implications of Large Language Model Code Assistants (2022, methodology): “Run-time analysis can also occur by using tools such as debuggers and sanitizers like ‘Address Sanitizer’ (ASAN) [36] and ‘Undefined Behavior Sanitizer’ (UBSAN) [37].”
SGXBOUNDS: Memory Safety for Shielded Execution (2017, result): “We have obtained similar results with SPEC CPU2006 and four real-world case studies: SQLite, Memcached, Apache, and Nginx.”
Examining Zero-Shot Vulnerability Repair with Large Language Models (2021, background): “The red highlighted line 7 is the original faulty line indicated by ASAN/the oracle.”
AsyncShock: Exploiting Synchronisation Bugs in Intel SGX Enclaves (2016, neutral): “free [10], or even with tools such as AddressSanitizer [22] that delay the reuse of recently freed memory or by changing the behaviour of the in-enclave memory allocator.”
CollAFL: Path Sensitive Fuzzing (2018, methodology): “It is worth noting that, we only utilize AddressSanitizer to triage crashes, but do not use it in CollAFL, due to its performance overhead.”
Fuzzing: A Survey for Roadmap (2022, background): “Note that, the indicators only show potential security issues, which are further veriied by security tools or manual eforts to conirm a vulnerability [85, 168, 175].”
NEZHA: Efficient Domain-Independent Differential Testing (2017, background): “SanitizerCoverage can be combined with one or more of Clang’s sanitizers, namely AddressSanitizer (ASAN) [57], UndefinedBehaviorSanitizer (UBSAN) [8], and MemorySanitizer (MSAN) [60], to achieve memory error detection during testing.”
Evaluating Fuzz Testing (2018, methodology): “To address this issue, we compiled each cxxfilt version with Address Sanitizer and Undefined Behavior Sanitizer (ASAN and UBSAN) [48], which adds dynamic checks for various errors including memory errors.”
Cores that don't count (2021, background): “Code sanitizers in modern tool chains (e.g., Address Sanitizer [22]), capable of detecting memory corruption (e.g. buffer-overflow, use-after-free), also provide useful signals.”
SoK: Eternal War in Memory (2013, methodology): “2) Object based approaches: Perhaps the most widely used tools to detect memory errors in practice is Valgrind’s Memcheck [30] tool and AddressSanitizer [59].”
The Art, Science, and Engineering of Fuzzing: A Survey (2018, background): “Address Sanitizer (ASan) [199] is a fast memory error detector that instruments programs at compile time.”
AFL++ : Combining Incremental Steps of Fuzzing Research (2020, methodology): “Recently, our QEMU mode was extended by Fioraldi, with QAsan [16], to support sanitization against heap violations incorporating a Dynamic Binary Translation based implementation of AddressSanitizer [38].”
Directed Greybox Fuzzing (2017, methodology): “A runtime checker [14, 35, 37] crashes the program when it detects an error for an execution.”
Coverage-Based Greybox Fuzzing as Markov Chain (2016, methodology): “Runtime checkers, such as ASAN [24], crash the program for executions where the program would not normally crash.”
Skyfire: Data-Driven Seed Generation for Fuzzing (2017, methodology): “For open-source projects, we compiled them with AddressSanitizer [35], and for closed-source project, we enabled Page Heap and Application Verifier [36].”
Twelve years of SAMtools and BCFtools (2020, methodology): “Serebryany K, Bruening D, Potapenko A, Vyukov D. AddressSanitizer: A Fast Address Sanity Checker.”
Code-pointer integrity (2014, methodology): “These approaches typically employ language modifications [25, 36], compiler modifications [13, 3, 17, 34, 43], or rewrite machine code binaries [38, 54, 53].”