Pith. sign in

REVIEW 3 major objections 4 minor 38 references

Tech-ASan: Two-stage check for Address Sanitizer

T0 review · 3 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Tech-ASan claims a two-stage magic-value check cuts ASan runtime overhead by 33.7% without giving up detection.

desk verdict Clever two-stage magic-value check, but the fast path misses straddling out-of-bounds accesses, so the 'no detection loss' claim doesn't hold. read the letter →

arxiv 2506.05022 v4 pith:MJCPVAKI submitted 2025-06-05 cs.SE cs.CR

Yixuan Cao , Yuhong Feng , Huafeng Li , Chongyi Huang , Fangcao Jian , Haoran Li , Xu Wang This is my paper
classification cs.SEcs.CR
keywords AddressSanitizermemorysafetytwo-stagecheckmagicvalueredundanteliminationloopoptimizationLLVM
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper sets out to speed up Address Sanitizer without weakening its detection. Its proposed system, Tech-ASan, replaces ASan's per-access shadow-memory check with a two-stage check: a fast comparison of the accessed value against a magic constant, and a slow ASan-style shadow check only on equality. On SPEC CPU2006 the authors measure 33.70% less runtime overhead than ASan and 17.89% less than ASan--, with equal detection on the Juliet suite (plus 56 wcscpy cases that ASan misses) and on 20 real CVEs. The claim, if correct, is that a drop-in ASan replacement can be both faster and slightly more capable.

What carries the argument

The load-bearing object is the magic-value comparison. Tech-ASan fills every redzone and every freed memory region with the constant byte 0x89, and defines MAGIC_VALUE_N as 0x89 repeated to the access width N. For a store, the inserted logic is `if (*p == MAGIC_VALUE_N) asan_check(p);` before the store; for a load, the instruction's own result is reused: `foo = *p; if (foo == MAGIC_VALUE_N) asan_check(p);`. The slow check is the original ASan shadow-byte check, implemented as a function call. The accompanying optimizer removes redundant checks, and its loop algorithm proves an access index stays within bounds by examining PHI-node incoming values and the dominance relation between the access and the loop's compare instructions.

What would settle it

Run an 8-byte read that starts four bytes before the end of a heap buffer whose trailing redzone bytes are 0x89 and whose in-bounds bytes are non-0x89; Tech-ASan's fast check sees an 8-byte value unequal to 0x8989898989898989 and proceeds, while ASan reports heap-buffer-overflow. A single such silence falsifies the paper's claim that detection capability is uncompromised.

Watch

Extended reading notes

Core claim

The central claim is that most ASan checks can be done with one value comparison instead of a shadow-memory load, and that the resulting tool preserves ASan's detection capability. Tech-ASan poisons redzones and freed regions with the byte 0x89, so an N-byte access that touches such a region carries an N-byte magic value; the fast stage checks `*p == MAGIC_VALUE_N` (reusing the loaded value for loads), and only on equality does it call a slow check that reads the shadow byte exactly as ASan does. The paper reports that this two-stage design, combined with an optimizer that removes redundant checks including those inside single-level loops, cuts SPEC CPU2006 overhead to 64.0% versus 97.7% for ASan and 81.89% for ASan--, while detecting all 9,301 buggy Juliet testcases that the adjusted suite contains and 56 more than ASan or ASan-- detect.

Load-bearing premise

The fast path assumes that any access ASan would flag loads a value exactly equal to the magic constant, so an N-byte access that straddles a valid object and a poisoned redzone—where only some bytes are 0x89—fails the comparison and is never sent to the slow check.

Editorial extensions

If this is right

  • Fuzzing and large-scale testing built on ASan would run roughly a third cheaper, so the same time budget could cover more executions or larger inputs.
  • Wide-character string operations such as wcscpy, which ASan and ASan-- do not intercept, become covered, closing a known false-negative class.
  • Binary size drops about 14.8% relative to ASan, which helps deployment in storage-constrained environments.
  • The loop-check elimination algorithm removes checks that ASan-- cannot remove, targeting a source that accounts for roughly 45% of ASan's check overhead.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: the magic-value comparison is not a sound proxy for shadow-memory validity on partial overflows, so a broader benchmark with cross-granule straddling accesses would likely reveal false negatives that ASan catches.
  • Editorial inference: the speedup is workload-dependent on how rarely data equals 0x89; programs that manipulate 0x89-heavy data would trigger slow checks more often and see a smaller gain.
  • Editorial inference: the two-stage idea could be made sound by comparing only the first and last byte of an N-byte access against the magic value, or by randomizing the magic value per allocation, at a small cost in fast-check complexity.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. Tech-ASan proposes a two-stage sanitizer check for Address Sanitizer: a fast stage compares the accessed memory value against a magic constant (0x89, repeated to form MAGIC_VALUE_N) and only on equality invokes ASan's shadow-memory slow check. The paper also presents a compile-time optimizer that eliminates redundant checks, including a loop-specific removal algorithm, and reports on SPEC CPU2006 a 33.70% lower runtime overhead than ASan and a 17.89% lower overhead than ASan--, together with a claim that Tech-ASan does not compromise ASan's detection capability. Detection experiments on the adjusted Juliet Test Suite and 20 CVEs are used to support the preservation-of-detection claim, with an additional claim of 56 fewer false negatives than ASan and ASan-- due to wcscpy interception.

Significance. If the safety claim were valid, this would be a practically valuable result: a drop-in ASan replacement with roughly 17 percentage points less overhead and additional wide-string coverage would be useful for fuzzing and testing pipelines. The paper contains an extensive evaluation across Juliet, CVE, SPEC CPU2006, compilation time, and binary size, and the authors make their adjusted Juliet suite publicly available. However, the central detection-equivalence claim is invalid as stated: the fast equality check misses a class of multi-byte out-of-bounds accesses that ASan reports, and the optimizer's loop-removal safety condition is not justified. The performance results therefore measure an unsound checker, and the claimed detection advantage rests on an unsubstantiated claim about wcscpy interception.

major comments (3)
  1. [3.2] The fast stage is an exact equality test: for a store, `if (*p == MAGIC_VALUE_N) asan_check(p);` and for a load, `if (foo == MAGIC_VALUE_N) asan_check(p);`. For an N-byte access (N = 2, 4, or 8) beginning inside an addressable object and extending into a poisoned redzone, the loaded value is a mixture of ordinary data and 0x89 bytes, so the comparison fails and the slow check is skipped. ASan's own N-byte shadow test, `k != 0 && (Addr & 7) + AccessSize > k`, reports exactly this partial out-of-bounds access. The same miss occurs for stores, and after such a store writes over redzone bytes, the poisoned location no longer contains the magic value either. This contradicts the paper's central claim in Section 4.1 that Tech-ASan preserves ASan's detection capability. The Juliet evaluation in Table 1 does not include a multi-byte access straddling an object/redzone boundary, so the false-negative class is not exposed.
  2. [3.3] Algorithm 1's safety condition for a variable index is that `mi dominates cmp` or `cmp dominates mi`, where `cmp` is some compare `index < c` with `0 <= c < size`. Dominance by `cmp` is not enough to ensure the comparison is true at `mi`: the compare may be used in a branch whose other edge reaches `mi`. For example, inside a loop, `c = (i < 10); if (c) ...; else buf[i] = 0;` makes `c` dominate the store even though the store executes precisely when `i >= 10`. The paper's informal justification in the paragraph after Listing 1 does not address this case, so redundant-check removal is not proven safety-preserving. A formal argument relating the branch outcome to the access path, or a stronger condition (e.g., that the true edge of the comparison dominates `mi`), is required.
  3. [3.1 / Table 1] The paper attributes 56 false negatives of ASan and ASan-- to a lack of `wcscpy()` interception, yet Section 3.1 gives no citation or reproduction for the claim that ASan in LLVM 20.1.0 overlooks `wcscpy`. Because the headline "56 fewer false negatives" is presented as a detection-capability advantage, this claim should be substantiated with a reference to compiler-rt source or a minimal testcase; otherwise the comparison in Table 1 is not interpretable as a detection improvement.
minor comments (4)
  1. [Abstract / Section 4.2] The 33.70% and 17.89% figures are absolute percentage-point differences between overhead ratios (97.70% - 64.00% and 81.89% - 64.00%). The relative reductions are about 34.5% and 21.9%; please report these values unambiguously.
  2. [3.2] The claim that the slow check trigger probability is "very low" is not quantified; adding the measured fast-check miss rate would help readers assess the mechanism's robustness.
  3. [3.4] No artifact or repository is provided for the Tech-ASan source, despite the implementation details in Section 3.4; an availability statement would aid reproducibility of Table 3.
  4. [4.3] Table 4 shows a large compilation-time increase for 400.perlbench under Tech-ASan (286% vs. 159% for ASan); a brief explanation of which optimization pass causes this would help readers interpret the usability claim.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; Tech-ASan's evaluation compares against external baselines and its magic-value check is a fixed design choice, not a fitted parameter.

full rationale

The paper's central claims—runtime overhead reduction of 33.70% over ASan and 17.89% over ASan--, and preservation of detection capability—are supported by direct measurements on SPEC CPU2006, the Juliet Test Suite, and CVE PoCs. No parameter is fitted to the reported outcomes: the magic value 0x89 is a fixed constant chosen by design, and the two-stage check's behavior is defined by the paper's own instrumentation logic rather than by the evaluation results. The detection comparison uses external baselines (ASan, ASan--, GiantSan, FloatZone), and the claimed advantage of 56 fewer false negatives is attributed to an added wcscpy interception, which is an implementation extension rather than a renamed input. There are no load-bearing self-citations: the paper cites prior work such as ASan-- and FloatZone as baselines or related work, but the authors of those works are not the present authors, and the cited results are not used to justify the paper's conclusions. The known concern with the fast equality check missing multi-byte accesses that straddle an object/redzone boundary is a soundness issue, not a circularity issue, because it concerns whether the tool preserves ASan's detection, not whether a claimed output is equivalent to an input by construction. Accordingly, no circular step can be exhibited under the required standard.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

The central claim rests on the correctness of the two-stage fast-check premise and on the performance assumption that the magic byte is rarely present in valid data. There are no fitted parameters; the magic value 0x89 is a hand-picked design constant.

free parameters (1)
  • MAGIC_VALUE (0x89) = 0x89
    This is a hand-picked constant used for the fast check; its performance benefit depends on the byte or multi-byte pattern being rare in valid data, and no sensitivity analysis is given.
assumptions (4)
  • domain assumption ASan's shadow memory encoding and poisoning semantics are correct and complete as a ground truth.
    Tech-ASan reuses ASan's shadow memory model (Section 3.1) and depends on it for the slow check and for correct poisoning.
  • ad hoc to paper An invalid memory access will always load a value entirely equal to the magic value, so the fast check will trigger the slow check.
    This is the core safety premise of the two-stage checker (Section 3.2). It is false for accesses that straddle valid and poisoned memory, since the loaded value mixes data bytes and 0x89 bytes.
  • domain assumption Filling redzones and freed memory with 0x89 does not alter the semantics of correct programs or of bug-triggering paths.
    Assumed in Section 3.1. Legitimate programs never read redzones, but a buggy program that reads them will see 0x89 instead of stale data; whether this masks bugs is not analyzed.
  • ad hoc to paper The dominator condition in Algorithm 1 (mi dominates cmp or cmp dominates mi) is sufficient for safety of loop check removal.
    Algorithm 1 lines 13-14 use this condition. It appears conservative, but the paper provides no formal proof and does not discuss loops with modified indices.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Tech-ASan: Two-stage check for Address Sanitizer." pith.science (2026). https://pith.science/paper/MJCPVAKI

@misc{pith2026250605022,
  author       = {Pith},
  title        = {Pith review of: Tech-ASan: Two-stage check for Address Sanitizer},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MJCPVAKI}},
  note         = {Machine review of arXiv:2506.05022}
}
read the original abstract

Address Sanitizer (ASan) is a sharp weapon for detecting memory safety violations, including temporal and spatial errors hidden in C/C++ programs during execution. However, ASan incurs significant runtime overhead, which limits its efficiency in testing large software. The overhead mainly comes from sanitizer checks due to the frequent and expensive shadow memory access. Over the past decade, many methods have been developed to speed up ASan by eliminating and accelerating sanitizer checks, however, they either fail to adequately eliminate redundant checks or compromise detection capabilities. To address this issue, this paper presents Tech-ASan, a two-stage check based technique to accelerate ASan with safety assurance. First, we propose a novel two-stage check algorithm for ASan, which leverages magic value comparison to reduce most of the costly shadow memory accesses. Second, we design an efficient optimizer to eliminate redundant checks, which integrates a novel algorithm for removing checks in loops. Third, we implement Tech-ASan as a memory safety tool based on the LLVM compiler infrastructure. Our evaluation using the SPEC CPU2006 benchmark shows that Tech-ASan outperforms the state-of-the-art methods with 33.70% and 17.89% less runtime overhead than ASan and ASan--, respectively. Moreover, Tech-ASan detects 56 fewer false negative cases than ASan and ASan-- when testing on the Juliet Test Suite under the same redzone setting.

Figures

Figures reproduced from arXiv: 2506.05022 by the authors.

Figure 1
Figure 1. Shadow memory model in a 64-bit address space [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. ASan’s redzones in heap, stack, and global regions, [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. The framework of Tech-ASan ASan’s sanitizer checks rely on obtaining the corresponding shadow address through shift and addition calculations, loading the shadow byte, and determining whether it is a memory safety violation via comparison that may be more than once. Frequent access to shadow memory destroys the locality of the program, which increases runtime overhead. Our design focuses on how to complete the sanit… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Examples of two-stage checks execution continues as normal. If they are equal, the access is po￾tentially located in a freed memory region or a redzone. However, since the program itself may legitimately use the same magic value, the access cannot be immediately classi…
Figure 5
Figure 5. Figure 5: The binary sizes of programs in SPEC CPU2006 benchmark (MB) [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

38 extracted references · 22 canonical work pages

  1. [1]

    Paul E Black. 2018. Juliet 1.3 test suite: Changes from 1.2 . US Department of Commerce, National Institute of Standards and Technology

    work page 2018

  2. [2]

    Derek Bruening and Saman Amarasinghe. 2004. Efficient, transparent, and comprehensive runtime code manipulation. (2004)

    work page 2004

  3. [3]

    Derek Bruening and Qin Zhao. 2011. Practical memory checking with Dr. Memory. In International Symposium on Code Generation and Optimization (CGO 2011) . 213–223. https://doi.org/10.1109/CGO.2011.5764689

    work page arXiv 2011

  4. [4]

    Dang, Petros Maniatis, and David Wagner

    Thurston H.Y. Dang, Petros Maniatis, and David Wagner. 2017. Oscar: A Practi- cal Page-Permissions-Based Scheme for Thwarting Dangling Pointers. In 26th USENIX Security Symposium (USENIX Security 17) . USENIX Association, Van- couver, BC, 815–832. https://www.usenix.org/conference/usenixsecurity17/ technical-sessions/presentation/dang

    work page 2017

  5. [5]

    Duck and Roland H

    Gregory J. Duck and Roland H. C. Yap. 2018. EffectiveSan: type and memory error detection using dynamically typed C/C++. SIGPLAN Not. 53, 4 (jun 2018), 181–195. https://doi.org/10.1145/3296979.3192388

    arXiv 2018

  6. [6]

    Rahul George, Mingming Chen, Kaiming Huang, Zhiyun Qian, Thomas La Porta, and Trent Jaeger. 2024. OPTISAN: Using Multiple Spatial Error Defenses to Optimize Stack Memory Protection within a Budget. In 33rd USENIX Security Symposium (USENIX Security 24) . USENIX Association, Philadelphia, PA, 7195–

    work page 2024

  7. [7]

    Floris Gorter, Enrico Barberis, Raphael Isemann, Erik van der Kouwe, Cris- tiano Giuffrida, and Herbert Bos. 2023. FloatZone: Accelerating Memory Er- ror Detection using the Floating Point Unit. In 32nd USENIX Security Sym- posium (USENIX Security 23) . USENIX Association, Anaheim, CA, 805–822. https://www.usenix.org/conference/usenixsecurity23/presentati...

    work page 2023

  8. [8]

    Floris Gorter, Koen Koning, Herbert Bos, and Cristiano Giuffrida. 2022. DangZero: Efficient Use-After-Free Detection via Direct Page Table Access. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (Los Angeles, CA, USA) (CCS ’22). Association for Computing Machinery, New York, NY, USA, 1307–1322. https://doi.org/10.1...

    arXiv 2022

Show all 38 references
  1. [9]

    Binfa Gui, Wei Song, and Jeff Huang. 2021. UAFSan: an object-identifier-based dynamic approach for detecting use-after-free vulnerabilities. In Proceedings of the 30th ACM SIGSOFT International Symposium on Software Testing and Analysis (Virtual, Denmark) (ISSTA 2021). Associa...

    2021

  2. [10]

    John L. Henning. 2006. SPEC CPU2006 benchmark descriptions. SIGARCH Comput. Archit. News 34, 4 (Sept. 2006), 1–17. https://doi.org/10.1145/1186736. 1186737

    2006 doi

  3. [11]

    Konrad Hohentanner, Florian Kasten, and Lukas Auer. 2023. HWASanIO: Detect- ing C/C++ Intra-object Overflows with Memory Shading. In Proceedings of the 12th ACM SIGPLAN International Workshop on the State Of the Art in Program Analysis (Orlando, FL, USA) (SOAP 2023). Associati...

    2023

  4. [12]

    Chris Lattner and Vikram Adve. 2004. LLVM: a compilation framework for lifelong program analysis & transformation. In International Symposium on Code Generation and Optimization, 2004. CGO 2004. 75–86. https://doi.org/10.1109/ CGO.2004.1281665

    2004 arXiv

  5. [13]

    Julian Lettner, Dokyung Song, Taemin Park, Per Larsen, Stijn Volckaert, and Michael Franz. 2018. PartiSan: Fast and Flexible Sanitization via Run-Time Partitioning. In Research in Attacks, Intrusions, and Defenses , Michael Bailey, Thorsten Holz, Manolis Stamatogiannakis, and ...

    2018

  6. [14]

    Yuan Li, Wende Tan, Zhizheng Lv, Songtao Yang, Mathias Payer, Ying Liu, and Chao Zhang. 2022. PACMem: Enforcing Spatial and Temporal Memory Safety via ARM Pointer Authentication. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (Los Ange...

    2022

  7. [15]

    Zhenpeng Lin, Zheng Yu, Ziyi Guo, Simone Campanoni, Peter Dinda, and Xinyu Xing. 2024. CAMP: Compiler and Allocator-based Heap Memory Pro- tection. In 33rd USENIX Security Symposium (USENIX Security 24) . USENIX As- sociation, Philadelphia, PA, 4015–4032. https://www.usenix.or...

    2024

  8. [16]

    Hao Ling, Heqing Huang, Chengpeng Wang, Yuandao Cai, and Charles Zhang

  9. [17]

    Tongping Liu, Charlie Curtsinger, and Emery D. Berger. 2016. DoubleTake: fast and precise error detection via evidence-based dynamic analysis. In Proceedings of the 38th International Conference on Software Engineering (Austin, Texas) (ICSE ’16). Association for Computing Mach...

    2016

  10. [19]

    Martin, and Steve Zdancewic

    Santosh Nagarakatte, Jianzhou Zhao, Milo M.K. Martin, and Steve Zdancewic

  11. [20]

    Nicholas Nethercote and Julian Seward. 2007. How to shadow every byte of memory used by a program. In Proceedings of the 3rd International Con- ference on Virtual Execution Environments (San Diego, California, USA) (VEE ’07). Association for Computing Machinery, New York, NY, ...

    2007

  12. [21]

    Nicholas Nethercote and Julian Seward. 2007. Valgrind: a framework for heavy- weight dynamic binary instrumentation. SIGPLAN Not. 42, 6 (jun 2007), 89–100. https://doi.org/10.1145/1273442.1250746

    2007

  13. [22]

    Arvind S Raj, Wil Gibbs, Fangzhou Dong, Jayakrishna Menon Vadayath, Michael Tompkins, Steven Wirsz, Yibo Liu, Zhenghao Hu, Chang Zhu, Gokulkr- ishna Praveen Menon, Brendan Dolan-Gavitt, Adam Doupé, Ruoyu Wang, Yan Shoshitaishvili, and Tiffany Bao. 2024. Fuzz to the Future: Unc...

    2024

  14. [23]

    Manuel Rigger, Roland Schatz, René Mayrhofer, Matthias Grimmer, and Hanspeter Mössenböck. 2018. Sulong, and Thanks for All the Bugs: Finding Errors in C Programs by Abstracting from the Native Execution Model.SIGPLAN Not. 53, 2 (mar 2018), 377–391. https://doi.org/10.1145/3296...

    2018

  15. [24]

    Konstantin Serebryany, Derek Bruening, Alexander Potapenko, and Dmitriy Vyukov. 2012. AddressSanitizer: A Fast Address Sanity Checker. In 2012 USENIX Annual Technical Conference (USENIX ATC 12) . USENIX Association, Boston, MA, 309–318. https://www.usenix.org/conference/atc12/...

    2012

  16. [25]

    Kostya Serebryany, Chris Kennelly, Mitch Phillips, Matt Denton, Marco Elver, Alexander Potapenko, Matt Morehouse, Vlad Tsyrklevich, Christian Holler, Julian Lettner, David Kilzer, and Lander Brandt. 2024. GWP-ASan: Sampling-Based Detection of Memory-Safety Bugs in Production. ...

    2024

  17. [26]

    Kostya Serebryany, Evgenii Stepanov, Aleksey Shlyapnikov, Vlad Tsyrklevich, and Dmitry Vyukov. 2018. Memory Tagging and how it improves C/C++ memory safety. CoRR abs/1802.09517 (2018). arXiv:1802.09517 http://arxiv.org/abs/1802. 09517

    2018 arXiv

  18. [27]

    László Szekeres, Mathias Payer, Tao Wei, and Dawn Song. 2013. SoK: Eternal War in Memory. In 2013 IEEE Symposium on Security and Privacy . 48–62. https: //doi.org/10.1109/SP.2013.13

    2013 doi

  19. [28]

    Emanuel Vintila, Philipp Zieris, and Julian Horsch. 2025. Evaluating the Ef- fectiveness of Memory Safety Sanitizers . In 2025 IEEE Symposium on Secu- rity and Privacy (SP) . IEEE Computer Society, Los Alamitos, CA, USA, 88–88. https://doi.org/10.1109/SP61157.2025.00088

    2025

  20. [29]

    Common Vulnerabilities. 2005. Common vulnerabilities and exposures. The MITRE Corporation,[online] A vailable: https://cve. mitre. org/index. html (2005)

    2005

  21. [30]

    Jonas Wagner, Volodymyr Kuznetsov, George Candea, and Johannes Kinder. 2015. High System-Code Security with Low Overhead. In 2015 IEEE Symposium on Security and Privacy. 866–879. https://doi.org/10.1109/SP.2015.58

    2015 doi

  22. [31]

    Meng Xu, Kangjie Lu, Taesoo Kim, and Wenke Lee. 2017. Bunshin: Compositing Security Mechanisms through Diversification. In 2017 USENIX Annual Techni- cal Conference (USENIX ATC 17) . USENIX Association, Santa Clara, CA, 271–

    2017

  23. [32]

    Jiang Zhang, Shuai Wang, Manuel Rigger, Pinjia He, and Zhendong Su. 2021. SanRazor: Reducing Redundant Sanitizer Checks in C/C++ Programs. In 15th USENIX Symposium on Operating Systems Design and Implementation (OSDI 21). USENIX Association, 479–494. https://www.usenix.org/con...

    2021

  24. [33]

    Yiyu Zhang, Tianyi Liu, Zewen Sun, Zhe Chen, Xuandong Li, and Zhiqiang Zuo. 2023. Catamaran: Low-Overhead Memory Safety Enforcement via Parallel Acceleration. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (Seattle, WA, USA) (IS...

    2023

  25. [34]

    Yuchen Zhang, Chengbin Pang, Georgios Portokalidis, Nikos Triandopoulos, and Jun Xu. 2022. Debloating Address Sanitizer. In 31st USENIX Security Symposium (USENIX Security 22) . USENIX Association, Boston, MA, 4345–4363. https: //www.usenix.org/conference/usenixsecurity22/pres...

    2022

  26. [283]

    https://www.usenix.org/conference/atc17/technical-sessions/presentation/ xu-meng

  27. [2009]

    Internetware 2025, June 20–22, 2025, Trondheim, Norway Yixuan Cao, Yuhong Feng, Huafeng Li, Chongyi Huang, Fangcao Jian, Haoran Li, and Xu Wang SIGPLAN Not

    SoftBound: highly compatible and complete spatial memory safety for c. Internetware 2025, June 20–22, 2025, Trondheim, Norway Yixuan Cao, Yuhong Feng, Huafeng Li, Chongyi Huang, Fangcao Jian, Haoran Li, and Xu Wang SIGPLAN Not. 44, 6 (June 2009), 245–258. https://doi.org/10.11...

    2025

  28. [2010]

    SIGPLAN Not

    CETS: compiler enforced temporal safety for C. SIGPLAN Not. 45, 8 (jun 2010), 31–40. https://doi.org/10.1145/1837855.1806657

    2010

  29. [2024]

    In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2 (, La Jolla, CA, USA,) (ASPLOS ’24)

    GIANTSAN: Efficient Memory Sanitization with Segment Folding. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2 (, La Jolla, CA, USA,) (ASPLOS ’24). Association for Computing Machinery, Ne...

  30. [7212]

    https://www.usenix.org/conference/usenixsecurity24/presentation/george

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.