pith. sign in

arxiv: 2509.22027 · v3 · submitted 2025-09-26 · 💻 cs.CR

NanoTag: Systems Support for Efficient Byte-Granular Overflow Detection on ARM MTE

Mingkai Li , Hang Ye , Joseph Devietti , Suman Jana , Tanvir Ahmed Khan This is my paper

Pith reviewed 2026-05-18 13:26 UTC · model grok-4.3

classification 💻 cs.CR
keywords memory safetybuffer overflowARM MTEbyte granularitytripwireScudo allocatorAddressSanitizer
0
0 comments X

The pith

NanoTag enables byte-granular buffer overflow detection on ARM MTE hardware using software tripwires.

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

This paper examines how ARM's Memory Tagging Extension (MTE) falls short in precision for detecting buffer overflows because of its 16-byte tag granularity. To improve this, the authors introduce NanoTag, a system that sets up tripwires on specific tag granules to trigger software-based checks for potential intra-granule overflows. For most accesses, it relies on MTE's hardware detection. The approach works on unmodified binaries with only small allocator modifications and aims to detect almost as many bugs as AddressSanitizer but with overhead close to MTE in sync mode.

Core claim

NanoTag detects buffer overflows at byte granularity by setting up a tripwire for tag granules that may require intra-granule overflow detection. The memory access to the tripwire causes additional overflow detection in the software while using MTE's hardware to detect bugs for the rest of the accesses. Implemented on the Scudo allocator, evaluations show it detects nearly as many memory safety bugs as ASAN while incurring similar run-time overhead to Scudo in MTE SYNC mode.

What carries the argument

The tripwire mechanism for tag granules, which selectively invokes software overflow detection on top of MTE hardware checks.

If this is right

  • NanoTag can detect more precise buffer overflows than standard MTE implementations.
  • It maintains runtime performance similar to MTE SYNC mode on Android devices.
  • Only minimal changes to existing memory allocators are needed for integration.
  • It applies to unmodified MTE-enabled binaries, simplifying deployment for testing.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • This approach might be adaptable to other memory tagging hardware beyond ARM.
  • Future hardware revisions could incorporate finer granularity if software tripwires prove effective.
  • The probabilistic aspect could be tuned for different testing scenarios to balance detection rate and overhead.

Load-bearing premise

The tripwire can be inserted with minimal allocator changes while keeping the detection-performance tradeoff acceptable for in-house testing.

What would settle it

A test where NanoTag misses many more bugs than ASAN or shows significantly higher overhead than MTE SYNC on the evaluated benchmarks and case studies.

Figures

Figures reproduced from arXiv: 2509.22027 by Hang Ye, Joseph Devietti, Mingkai Li, Suman Jana, Tanvir Ahmed Khan.

Figure 1
Figure 1. Figure 1: An overview of ARM MTE. Locks and keys represent memory and address tags, respectively. Addressable bytes are shad￾owed. The middle tag granule is a short granule. MTE detects both underflow (1) and overflow (3) across the tag granule boundary. However, it ignores the intra-granule buffer overflow (2). While accessing memory bytes with a pointer, the pointer carries a key associated with a lock that protec… view at source ↗
Figure 2
Figure 2. Figure 2: CVE-2024-12084 [32], an intra-granule heap-based buffer overflow bug in rsync that becomes a silent data corruption in MTE, while both ASAN and NanoTag detect it. Results. In our experiment, both ASAN and Scudo do not re￾port any of the benign test cases as bugs. Therefore, we only show the results of buggy test cases in [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Percentage of vulnerable memory allocations in SPEC CPU 2017 benchmarks. 86.57% of all allocations in SPEC CPU 2017 benchmarks include short granules, leading to potential intra￾granule buffer overflows. The only outlier is 505.mcf_r (0.05%). typically larger than SUM_LENGTH, as defined in md-defined.h. As the size of sum_buf (40 bytes) is not a multiple of 16 bytes, the last tag granule in the memory allo… view at source ↗
Figure 4
Figure 4. Figure 4: NanoTag’s workflow. Blue blocks specify additional components in NanoTag, while white blocks denote unmodified components in MTE’s hardware and software. Slow Start Sampling Phase new ShortGranule SetTripwire(1) AllocCount++ AllocCount > AllocThreshold ^ SetTripwire(SamplingRate) new ShortGranule [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: NanoTag’s sampling-based tripwire allocation. which is different from other tags in the same memory allo￾cation. Similar to HWASAN [22], NanoTag sets the tripwire tag as the number of addressable bytes in the short granule, which is 0x8 for the short granule in [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Examples of memory access patterns of ARM load and store instructions. The red block represents the tripwire. The mem￾ory access can be unaligned, e.g., access 3, and may access multiple tag granules, e.g., access 2 and 3. the instruction accesses short granule’s addressable bytes by calculating both the end address of addressable bytes in the short granule (permitted, line 6~7) and the end address of the … view at source ↗
Figure 7
Figure 7. Figure 7: Delegation-escalation-revocation in NanoTag. A red block denotes the program instruction processor currently executes, blue blocks represent NanoTag’s byte-granular overflow detection and tag mismatch recovery, and lightning symbols denote tag mis￾match fault and trap. a tag mismatch fault in another tag granule. NanoTag also avoids emulating the exception instruction as, in software, it is challenging to … view at source ↗
Figure 8
Figure 8. Figure 8: The run-time overhead of MTE-enabled Scudo, Nan￾oTag, and ASAN for SPEC CPU 2017 benchmarks compared to a Scudo baseline with MTE disabled. In terms of geometric mean, NanoTag incurs an overhead of 12.50% similar to Scudo’s 11.98% overhead in MTE SYNC mode. free (CWE415) and use-after-free (CWE416), NanoTag performs similarly to Scudo, detecting 98.37% and 96.69% double free and use-after-free bugs, respec… view at source ↗
read the original abstract

Memory safety bugs, such as buffer overflows and use-after-frees, are the leading causes of software safety issues in production. Software-based approaches, e.g., Address Sanitizer (ASAN), can detect such bugs with high precision, but with prohibitively high overhead. ARM's Memory Tagging Extension (MTE) offers a promising alternative to detect these bugs in hardware with a much lower overhead. In this paper, we perform a thorough investigation of the first production implementation of ARM MTE (Google Pixel 8) and observe that MTE can only achieve coarse precision in bug detection compared with software-based approaches such as ASAN, mainly due to its 16-byte tag granularity. To address this issue, we present NANOTAG, a system to probabilistically detect buffer overflows at byte granularity in unmodified MTE-enabled binaries with minimal changes to memory allocators, introducing an explicit detection-performance tradeoff for in-house testing. NANOTAG detects buffer overflows at byte granularity by setting up a tripwire for tag granules that may require intra-granule overflow detection. The memory access to the tripwire causes additional overflow detection in the software while using MTE's hardware to detect bugs for the rest of the accesses. We implement NANOTAG based on the Scudo Hardened Allocator, the default memory allocator on Android since Android 11. Our evaluation results across popular benchmarks and real-world case studies show that NANOTAG detects nearly as many memory safety bugs as ASAN while incurring similar run-time overhead to Scudo Hardened Allocator in MTE SYNC mode.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper presents NanoTag, a system built on the Scudo allocator that augments ARM MTE to achieve byte-granular buffer overflow detection. It does so by placing tripwire tags on selected granules; accesses hitting a tripwire divert to a software check while all other accesses use MTE hardware. The central claim is that this yields detection rates nearly matching ASAN while incurring runtime overhead comparable to Scudo in MTE SYNC mode, with only minimal allocator modifications and an explicit detection-performance tradeoff for in-house testing.

Significance. If the performance and detection claims hold under broader workloads, NanoTag would offer a practical middle ground between coarse-grained hardware tagging and high-overhead software sanitizers, enabling finer-grained memory safety checks in production binaries with modest changes to existing allocators.

major comments (2)
  1. [Evaluation] Evaluation section: the abstract states that NanoTag detects nearly as many bugs as ASAN with Scudo-like overhead, yet reports no error bars, exact bug counts, or details on post-hoc exclusions and workload selection. Without these, the quantitative support for the 'near-ASAN' and 'similar overhead' claims cannot be assessed.
  2. [Design / Overhead Analysis] Tripwire design and § on overhead analysis: the claim that software diversions remain rare enough to preserve Scudo-MTE overhead levels rests on the assumption that boundary accesses are infrequent. Workloads with many small allocations or frequent end-of-object accesses could make tripwire hits common, causing the software path to dominate; the current benchmark suite may under-sample these cases.
minor comments (1)
  1. [Abstract] Abstract: the phrase 'probabilistically detect' is used without specifying the underlying probability model or how it interacts with MTE's tag collision probability.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback. We address each major comment below and indicate the revisions planned for the next version of the manuscript.

read point-by-point responses

  1. Referee: [Evaluation] Evaluation section: the abstract states that NanoTag detects nearly as many bugs as ASAN with Scudo-like overhead, yet reports no error bars, exact bug counts, or details on post-hoc exclusions and workload selection. Without these, the quantitative support for the 'near-ASAN' and 'similar overhead' claims cannot be assessed.

    Authors: We agree that additional details are needed to allow readers to fully evaluate the claims. In the revised manuscript we will add error bars to the relevant figures based on repeated runs of the benchmarks. We will also include a table reporting the exact bug counts detected by NanoTag versus ASAN for each workload and case study, together with a description of how the workloads were chosen and any post-hoc exclusions that were applied. revision: yes

  2. Referee: [Design / Overhead Analysis] Tripwire design and § on overhead analysis: the claim that software diversions remain rare enough to preserve Scudo-MTE overhead levels rests on the assumption that boundary accesses are infrequent. Workloads with many small allocations or frequent end-of-object accesses could make tripwire hits common, causing the software path to dominate; the current benchmark suite may under-sample these cases.

    Authors: We acknowledge that the overhead claims depend on boundary accesses remaining infrequent. The overhead analysis section already shows that the software path is taken only rarely under the evaluated workloads, keeping overall cost close to Scudo-MTE. To address the concern about possible under-sampling, we will add a new paragraph discussing the allocation-size distribution in our benchmark suite and include results from microbenchmarks that deliberately stress small allocations and end-of-object accesses. This will make the conditions under which the tripwire mechanism preserves low overhead more explicit. revision: partial

Circularity Check

0 steps flagged

No circularity: claims rest on implementation and benchmark measurements

full rationale

The paper describes an implemented system (NanoTag on Scudo allocator) that uses MTE hardware for most accesses and software tripwire checks for intra-granule cases. Central claims about detection precision and overhead are supported by reported runtime measurements on benchmarks and case studies, not by equations, fitted parameters, or self-referential definitions. No load-bearing step reduces to its own inputs by construction; the design is self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The design rests on the existing 16-byte MTE hardware behavior and on the ability to modify allocators without breaking binaries. The tripwire construct is the main new element introduced without independent evidence outside the paper.

axioms (1)
  • domain assumption ARM MTE hardware tags memory at 16-byte granularity and can only detect overflows that cross granule boundaries
    Stated directly in the abstract as the core limitation being addressed.
invented entities (1)
  • Tripwire for selected tag granules no independent evidence
    purpose: To force software-level byte-granular overflow checks on accesses that might otherwise be missed by MTE
    New mechanism introduced by NanoTag; no external falsifiable prediction or independent evidence is provided in the abstract.

pith-pipeline@v0.9.0 · 5826 in / 1346 out tokens · 41349 ms · 2026-05-18T13:26:15.367764+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

105 extracted references · 105 canonical work pages · 1 internal anchor

  1. [1]

    [n. d.]. 3.2.2 The GNU Allocator.https://www.gnu.org/software/libc/ manual/html_node/The-GNU-Allocator.html. [Online; accessed 1- April-2025]

    work page 2025

  2. [2]

    [n. d.]. aarch64: MTE compatible strcpy.https://github.com/bminor/ glibc/commit/bb2c12aecbd26a8d29f63b51b80b7c84e65d1818. [Online; accessed 1-April-2025]

    work page 2025

  3. [3]

    d.].About the Debug Register Interface.https://developer.arm.com/ documentation/ddi0379/a/Debug-Register-Interfaces/About-the- Debug-Register-Interface?lang=en

    [n. d.].About the Debug Register Interface.https://developer.arm.com/ documentation/ddi0379/a/Debug-Register-Interfaces/About-the- Debug-Register-Interface?lang=en

    work page

  4. [4]

    [n. d.]. AddressSanitizer | Anroid Open Source Project.https://source. android.com/docs/security/test/asan. [Online; accessed 1-April-2025]

    work page 2025

  5. [5]

    d.].AmpereOne Product Brief.https://amperecomputing.com/ briefs/ampereone-family-product-brief

    [n. d.].AmpereOne Product Brief.https://amperecomputing.com/ briefs/ampereone-family-product-brief

    work page

  6. [6]

    [n. d.]. ARM A-profile A64 Instruction Set Architecture | Loads and Stores.https://developer.arm.com/documentation/ddi0602/2024-09/ Index-by-Encoding/Loads-and-Stores?lang=en. [Online; accessed 1-April-2025]

    work page 2024

  7. [7]

    [n. d.]. Armv8.5-A Memory Tagging Extension White Paper.https:// developer.arm.com/documentation/102925/latest/. [Online; accessed 1-April-2025]

    work page 2025

  8. [8]

    d.].A voiding runcpu - CPU 2017.https://www.spec.org/cpu2017/ Docs/runcpu-avoidance.html

    [n. d.].A voiding runcpu - CPU 2017.https://www.spec.org/cpu2017/ Docs/runcpu-avoidance.html

    work page 2017

  9. [9]

    [n. d.]. chroot(2) - Linux manual page.https://man7.org/linux/man- pages/man2/chroot.2.html. [Online; accessed 1-April-2025]

    work page 2025

  10. [10]

    d.].Clang 14.0.0 documentation.https://releases.llvm.org/14.0.0/ tools/clang/docs/index.html

    [n. d.].Clang 14.0.0 documentation.https://releases.llvm.org/14.0.0/ tools/clang/docs/index.html

    work page

  11. [11]

    [n. d.]. CVE-2024-12084 - Red Hat Customer Portal.https://access. redhat.com/security/cve/CVE-2024-12084. [Online; accessed 1-April- 2025]

    work page 2024

  12. [12]

    [n. d.]. CWE - 2024 CWE Top 25 Most Dangerous Software Weaknesses. https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html. [On- line; accessed 1-April-2025]

    work page 2024

  13. [13]

    [n. d.]. Enhanced security through Memory Tagging Extension. https://community.arm.com/arm-community-blogs/b/architectures- and-processors-blog/posts/enhanced-security-through-mte. [Online; accessed 1-April-2025]

    work page 2025

  14. [14]

    d.].EnvironmentVariables - Community Help Wiki.https://help

    [n. d.].EnvironmentVariables - Community Help Wiki.https://help. ubuntu.com/community/EnvironmentVariables

    work page

  15. [15]

    d.].facebook/infer: A static analyzer for Java, C, C++, and Objective- C.https://github.com/facebook/infer

    [n. d.].facebook/infer: A static analyzer for Java, C, C++, and Objective- C.https://github.com/facebook/infer

    work page

  16. [16]

    [n. d.]. Geekbench 6 - Apps on Google Play.https://play.google.com/ store/apps/details?id=com.primatelabs.geekbench6&hl=en_US. [On- line; accessed 1-April-2025]

    work page 2025

  17. [17]

    [n. d.]. Geekbench 6 - Cross-Platform Benchmark.https://www. geekbench.com/. [Online; accessed 1-April-2025]

    work page 2025

  18. [18]

    [n. d.]. Geekbench 6 on the App Store.https://apps.apple.com/us/app/ geekbench-6/id1565728895. [Online; accessed 1-April-2025]

    work page 2025

  19. [19]

    [n. d.]. Getting started - Termux Wiki.https://wiki.termux.com/wiki/ Getting_started. [Online; accessed 1-April-2025]

    work page 2025

  20. [20]

    [n. d.]. glibc/sysdeps/aarch64/strcpy.S.https://github.com/bminor/ glibc/blob/ce2f26a22e6b6f5c108d156afd9b43a452bb024c/sysdeps/ aarch64/strcpy.S. [Online; accessed 1-April-2025]

    work page 2025

  21. [21]

    [n. d.]. The GNU C Library - GNU Project - Free Software Foundation. https://www.gnu.org/software/libc/. [Online; accessed 1-April-2025]

    work page 2025

  22. [22]

    [n. d.]. Hardware-assisted AddressSanitizer | Android Open Source Project.https://source.android.com/docs/security/test/hwasan. [On- line; accessed 1-April-2025]

    work page 2025

  23. [23]

    [n. d.]. Juliet C/C++ 1.3 - NIST Software Assurance Reference Dataset. https://samate.nist.gov/SARD/test-suites/112. [Online; accessed 1- April-2025]

    work page 2025

  24. [24]

    [n. d.]. LeakSanitizer - Clang 21.0.0git documentation.https://clang. llvm.org/docs/LeakSanitizer.html. [Online; accessed 1-April-2025]

    work page 2025

  25. [25]

    d.].llvm_mode persistent mode.https://github.com/AFLplusplus/ AFLplusplus/blob/stable/instrumentation/README.persistent_ mode.md

    [n. d.].llvm_mode persistent mode.https://github.com/AFLplusplus/ AFLplusplus/blob/stable/instrumentation/README.persistent_ mode.md

    work page

  26. [26]

    [n. d.]. Memory corruption bug uncovered by MTE fixed by Google after GrapheneOS report.https://discuss.grapheneos.org/d/12628- memory-corruption-bug-uncovered-by-mte-fixed-by-google-after- grapheneos-report. [Online; accessed 1-April-2025]

    work page 2025

  27. [27]

    [n. d.]. Memory safety | Android Open Source Project.https://source. android.com/docs/security/test/memory-safety. [Online; accessed 1-April-2025]

    work page 2025

  28. [28]

    [n. d.]. Memory Tagging Extension (MTE) in AArch64 Linux.http://docs.kernel.org/arch/arm64/memory-tagging- extension.html#memory-tagging-extension-mte-in-aarch64-linux. [Online; accessed 1-April-2025]

    work page 2025

  29. [29]

    [n. d.]. MemTagSanitizer - LLVM 21.0.0git documentation.https: //llvm.org/docs/MemTagSanitizer.html. [Online; accessed 1-April- 2025]

    work page 2025

  30. [30]

    [n. d.]. MTE bootloader support.https://source.android.com/docs/ security/test/memory-safety/bootloader-support. [Online; accessed 1-April-2025]

    work page 2025

  31. [31]

    [n. d.]. MTE modes.https://developer.arm.com/documentation/ 108035/0100/How-does-MTE-work-/MTE-modes. [Online; accessed 1-April-2025]

    work page 2025

  32. [32]

    [n. d.]. NVD - CVE-2024-12084.https://nvd.nist.gov/vuln/detail/CVE- 2024-12084. [Online; accessed 1-April-2025]

    work page 2024

  33. [33]

    d.].Overview: Breakpoints and Watchpoints.https: //developer.arm.com/documentation/dui0446/z/controlling-target- execution/overview--breakpoints-and-watchpoints

    [n. d.].Overview: Breakpoints and Watchpoints.https: //developer.arm.com/documentation/dui0446/z/controlling-target- execution/overview--breakpoints-and-watchpoints

    work page

  34. [34]

    [n. d.]. Preview Versions - Geekbench.https://www.geekbench.com/ preview/. [Online; accessed 1-April-2025]

    work page 2025

  35. [35]

    [n. d.]. Project Zero: First Handset with MTE on the mar- ket.https://googleprojectzero.blogspot.com/2023/11/first-handset- with-mte-on-market.html. [Online; accessed 1-April-2025]

    work page 2023

  36. [36]

    d.].Release v1.2.1, HexHive/magma.https://github.com/HexHive/ magma/tree/v1.2.1

    [n. d.].Release v1.2.1, HexHive/magma.https://github.com/HexHive/ magma/tree/v1.2.1

    work page

  37. [37]

    [n. d.]. rsync.https://rsync.samba.org/. [Online; accessed 1-April- 2025]

    work page 2025

  38. [38]

    d.].RSync: Heap Buffer Overflow, Info Leak, Server Leaks, Path Traversal and Safe links Bypass.https://github.com/google/security- research/security/advisories/GHSA-p5pg-x43v-mvqj

    [n. d.].RSync: Heap Buffer Overflow, Info Leak, Server Leaks, Path Traversal and Safe links Bypass.https://github.com/google/security- research/security/advisories/GHSA-p5pg-x43v-mvqj

    work page

  39. [39]

    [n. d.]. rsync/lib/md-defines.h.https://github.com/RsyncProject/ rsync/blob/9615a2492bbf96bc145e738ebff55bbb91e0bbee/lib/md- defines.h#L11-L21. [Online; accessed 1-April-2025]

    work page 2025

  40. [40]

    [n. d.]. rsync/rsync.c.https://github.com/RsyncProject/rsync/blob/ 9615a2492bbf96bc145e738ebff55bbb91e0bbee/rsync.h#L955-L962. 12 [Online; accessed 1-April-2025]

    work page 2025

  41. [41]

    [n. d.]. rsync/sender.c.https://github.com/RsyncProject/rsync/blob/ 9615a2492bbf96bc145e738ebff55bbb91e0bbee/sender.c#L96-L100. [Online; accessed 1-April-2025]

    work page 2025

  42. [42]

    [n. d.]. Scudo | Android Open Source Project.https://source.android. com/docs/security/test/scudo. [Online; accessed 1-April-2025]

    work page 2025

  43. [43]

    [n. d.]. Scudo Hardened Allocator - LLVM 21.0.0git documentation. https://llvm.org/docs/ScudoHardenedAllocator.html. [Online; ac- cessed 1-April-2025]

    work page 2025

  44. [44]

    [n. d.]. Signal Handling (The GNU C Library).https://www.gnu.org/ software/libc/manual/html_node/Signal-Handling.html. [Online; accessed 1-April-2025]

    work page 2025

  45. [45]

    d.].SPEC CPU®2017 benchmark.https://www.spec.org/cpu2017/

    [n. d.].SPEC CPU®2017 benchmark.https://www.spec.org/cpu2017/

    work page 2017

  46. [46]

    d.].System V contexts (The GNU C Library).https://www.gnu.org/ software/libc/manual/html_node/System-V-contexts.html

    [n. d.].System V contexts (The GNU C Library).https://www.gnu.org/ software/libc/manual/html_node/System-V-contexts.html

    work page

  47. [47]

    [n. d.]. Tagged pointers | Android Open Source Project.https://source. android.com/docs/security/test/tagged-pointers. [Online; accessed 1-April-2025]

    work page 2025

  48. [48]

    [n. d.]. Termux | The main termux site and help pages.https://termux. dev/en/. [Online; accessed 1-April-2025]

    work page 2025

  49. [49]

    d.].ThunderX2 - Cavium - WikiChip.https://en.wikichip.org/wiki/ cavium/thunderx2

    [n. d.].ThunderX2 - Cavium - WikiChip.https://en.wikichip.org/wiki/ cavium/thunderx2

    work page

  50. [50]

    [n. d.]. Where is the MTE Tag stored and Checked?https://developer. arm.com/documentation/ka005620/1-0/?lang=en. [Online; accessed 1-April-2025]

    work page 2025

  51. [51]

    Yechan Bae, Youngsuk Kim, Ammar Askar, Jungwon Lim, and Taesoo Kim. 2021. Rudra: Finding Memory Safety Bugs in Rust at the Ecosys- tem Scale. InSOSP ’21: ACM SIGOPS 28th Symposium on Operating Systems Principles, Virtual Event / Koblenz, Germany, October 26-29, 2021, Robbert van Renesse and Nickolai Zeldovich (Eds.). ACM, 84–99. https://doi.org/10.1145/34...

    work page doi:10.1145/3477132.3483570 2021

  52. [52]

    Xingman Chen, Yinghao Shi, Zheyu Jiang, Yuan Li, Ruoyu Wang, Haixin Duan, Haoyu Wang, and Chao Zhang. 2023. MTSan: A Feasible and Practical Memory Sanitizer for Fuzzing COTS Binaries. In32nd USENIX Security Symposium, USENIX Security 2023, Anaheim, CA, USA, August 9-11, 2023, Joseph A. Calandrino and Carmela Troncoso (Eds.). USENIX Association, 841–858.ht...

    work page 2023

  53. [53]

    Yu-Chang Chen and Shih-Wei Li. 2024. HeMate: Enhancing Heap Security through Isolating Primitive Types with Arm Memory Tag- ging Extension. InProceedings of the 19th International Conference on A vailability, Reliability and Security, ARES 2024, Vienna, Austria, 30 July 2024 - 2 August 2024. ACM, 30:1–30:11.https://doi.org/10.1145/ 3664476.3664492

    work page arXiv 2024

  54. [54]

    Peter Collingbourne. [n. d.]. scudo: Use DC GZVA instruc- tion in storeTags().https://github.com/llvm/llvm-project/commit/ 46c59d91dc7a39cc98be7a68d6dc60f3e8a35df0. [Online; accessed 1- April-2025]

    work page 2025

  55. [55]

    Joe Devietti, Colin Blundell, Milo M. K. Martin, and Steve Zdancewic

    work page

  56. [56]

    (2008), 103–114.https://doi.org/10.1145/ 1346281.1346295

    Hardbound: architectural support for spatial safety of the C programming language. (2008), 103–114.https://doi.org/10.1145/ 1346281.1346295

    work page arXiv 2008

  57. [57]

    Sushant Dinesh, Nathan Burow, Dongyan Xu, and Mathias Payer

    work page

  58. [58]

    KARONTE: Detecting insecure multi-binary interactions in embedded firmware

    RetroWrite: Statically Instrumenting COTS Binaries for Fuzzing and Sanitization. In2020 IEEE Symposium on Security and Privacy, SP 2020, San Francisco, CA, USA, May 18-21, 2020. IEEE, 1497–1511. https://doi.org/10.1109/SP40000.2020.00009

    work page doi:10.1109/sp40000.2020.00009 2020

  59. [59]

    Duck and Roland H

    Gregory J. Duck and Roland H. C. Yap. 2016. Heap bounds protection with low fat pointers. InProceedings of the 25th International Conference on Compiler Construction, CC 2016, Barcelona, Spain, March 12-18, 2016, Ayal Zaks and Manuel V. Hermenegildo (Eds.). ACM, 132–142. https://doi.org/10.1145/2892208.2892212

    work page doi:10.1145/2892208.2892212 2016

  60. [60]

    Duck and Roland H

    Gregory J. Duck and Roland H. C. Yap. 2018. EffectiveSan: type and memory error detection using dynamically typed C/C++. InProceed- ings of the 39th ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDI 2018, Philadelphia, PA, USA, June 18-22, 2018, Jeffrey S. Foster and Dan Grossman (Eds.). ACM, 181–195. https://doi.org/10.1145/3...

    work page doi:10.1145/3192366.3192388 2018

  61. [61]

    Duck, Roland H

    Gregory J. Duck, Roland H. C. Yap, and Lorenzo Cavallaro. 2017. Stack Bounds Protection with Low Fat Pointers. In24th Annual Network and Distributed System Security Symposium, NDSS 2017, San Diego, California, USA, February 26 - March 1, 2017. The Inter- net Society.https://www.ndss-symposium.org/ndss2017/ndss-2017- programme/stack-object-protection-low-f...

    work page 2017

  62. [62]

    Reza Mirzazade Farkhani, Mansour Ahmadi, and Long Lu. 2021. PTAuth: Temporal Memory Safety via Robust Points-to Authenti- cation. In30th USENIX Security Symposium, USENIX Security 2021, August 11-13, 2021, Michael D. Bailey and Rachel Greenstadt (Eds.). USENIX Association, 1037–1054.https://www.usenix.org/conference/ usenixsecurity21/presentation/mirzazade

    work page 2021

  63. [63]

    Andrea Fioraldi, Daniele Cono D’Elia, and Leonardo Querzoni. 2020. Fuzzing Binaries for Memory Safety Errors with QASan. InIEEE Secure Development, SecDev 2020, Atlanta, GA, USA, September 28-30, 2020. IEEE, 23–30.https://doi.org/10.1109/SECDEV45635.2020.00019

    work page doi:10.1109/secdev45635.2020.00019 2020

  64. [64]

    Andrea Fioraldi, Dominik Christian Maier, Heiko Eißfeldt, and Marc Heuse. 2020. AFL++ : Combining Incremental Steps of Fuzzing Research. In14th USENIX Workshop on Offensive Technologies, WOOT 2020, August 11, 2020, Yuval Yarom and Sarah Zennou (Eds.). USENIX Association.https://www.usenix.org/conference/woot20/ presentation/fioraldi

    work page 2020

  65. [65]

    Floris Gorter, Taddeus Kroes, Herbert Bos, and Cristiano Giuffrida

    work page

  66. [66]

    Choquette-Choo, Daniel Paleka, Will Pearce, Hyrum Anderson, Andreas Terzis, Kurt Thomas, and Florian Tramer

    Sticky Tags: Efficient and Deterministic Spatial Memory Error Mitigation using Persistent Memory Tags. InIEEE Symposium on Security and Privacy, SP 2024, San Francisco, CA, USA, May 19-23, 2024. IEEE, 4239–4257.https://doi.org/10.1109/SP54263.2024.00263

    work page doi:10.1109/sp54263.2024.00263 2024

  67. [67]

    Andreas Hager-Clukas and Konrad Hohentanner. 2024. DMTI: Ac- celerating Memory Error Detection in Precompiled C/C++ Binaries with ARM Memory Tagging Extension. InProceedings of the 19th ACM Asia Conference on Computer and Communications Security, ASIA CCS 2024, Singapore, July 1-5, 2024, Jianying Zhou, Tony Q. S. Quek, Debin Gao, and Alvaro A. Cárdenas (E...

    work page doi:10.1145/3634737.3637655 2024

  68. [68]

    Reed Hastings and Bob Joyce. [n. d.]. Purify: A tool for detecting memory leaks and access errors in C and C++ programs. InProceedings of the Winter 1992 USENIX Conference. 125–138

    work page 1992

  69. [69]

    Ahmad Hazimeh, Adrian Herrera, and Mathias Payer. 2020. Magma: A Ground-Truth Fuzzing Benchmark.Proc. ACM Meas. Anal. Comput. Syst.4, 3 (2020), 49:1–49:29.https://doi.org/10.1145/3428334

    work page doi:10.1145/3428334 2020

  70. [70]

    Juhee Kim, Jinbum Park, Yoochan Lee, Chengyu Song, Taesoo Kim, and Byoungyoung Lee. 2024. PeTAL: Ensuring Access Control Integrity against Data-only Attacks on Linux. InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, CCS 2024, Salt Lake City, UT, USA, October 14-18, 2024, Bo Luo, Xiaojing Liao, Jun Xu, Engin Kirda...

    work page doi:10.1145/3658644.3690184 2024

  71. [71]

    Juhee Kim, Jinbum Park, Sihyeon Roh, Jaeyoung Chung, Youngjoo Lee, Taesoo Kim, and Byoungyoung Lee. 2025. Tiktag: Breaking ARM’s Memory Tagging Extension with Speculative Execution. In IEEE Symposium on Security and Privacy, SP 2025, San Francisco, CA, USA, May 12-15, 2025, Marina Blanton, William Enck, and Cristina Nita-Rotaru (Eds.). IEEE, 4063–4081.htt...

    work page doi:10.1109/sp61157 2025

  72. [72]

    Guoren Li, Hang Zhang, Jinmeng Zhou, Wenbo Shen, Yulei Sui, and Zhiyun Qian. 2023. A Hybrid Alias Analysis and Its Application to Global Variable Protection in the Linux Kernel. In32nd USENIX 13 Security Symposium, USENIX Security 2023, Anaheim, CA, USA, Au- gust 9-11, 2023, Joseph A. Calandrino and Carmela Troncoso (Eds.). USENIX Association, 4211–4228.h...

    work page 2023

  73. [73]

    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. InProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, CCS 2022, Los Angeles, CA, USA, November 7-11, 2022, Heng Yin, Angelos Stavrou, Cas Creme...

    work page doi:10.1145/3548606.3560598 2022

  74. [74]

    Hans Liljestrand, Carlos Chinea Perez, Rémi Denis-Courmont, Jan- Erik Ekberg, and N. Asokan. 2022. Color My World: Deterministic Tagging for Memory Safety.CoRRabs/2204.03781 (2022).https: //doi.org/10.48550/ARXIV.2204.03781arXiv:2204.03781

    work page doi:10.48550/arxiv.2204.03781arxiv:2204.03781 2022

  75. [75]

    Soo-Yee Lim, Tanya Prasad, Xueyuan Han, and Thomas Pasquier

    work page

  76. [76]

    InProceedings of the 2024 on Cloud Computing Security Workshop, CCSW 2024, Salt Lake City, UT, USA, October 14-18, 2024, Apostolos P

    SafeBPF: Hardware-assisted Defense-in-depth for eBPF Kernel Extensions. InProceedings of the 2024 on Cloud Computing Security Workshop, CCSW 2024, Salt Lake City, UT, USA, October 14-18, 2024, Apostolos P. Fournaris and Paolo Palmieri (Eds.). ACM, 80–94.https: //doi.org/10.1145/3689938.3694781

    work page doi:10.1145/3689938.3694781 2024

  77. [77]

    Hao Ling, Heqing Huang, Chengpeng Wang, Yuandao Cai, and Charles Zhang. 2024. GIANTSAN: Efficient Memory Sanitization with Seg- ment Folding. InProceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, ASPLOS 2024, La Jolla, CA, USA, 27 April 2024- 1 May 2024, Rajiv Gupta, Nael...

    work page doi:10.1145/3620665.3640391 2024

  78. [78]

    Shrobe, Mathias Payer, Hamed Okhravi, and Nathan Burow

    Derrick Paul McKee, Yianni Giannaris, Carolina Ortega, Howard E. Shrobe, Mathias Payer, Hamed Okhravi, and Nathan Burow. 2022. Preventing Kernel Hacks with HAKCs. In29th Annual Network and Distributed System Security Symposium, NDSS 2022, San Diego, Califor- nia, USA, April 24-28, 2022. The Internet Society.https://www.ndss- symposium.org/ndss-paper/auto-...

    work page 2022

  79. [79]

    Matt Miller. 2019.Trends, Challenge, and Shifts in Software Vulner- ability Mitigation.https://github.com/Microsoft/MSRC-Security- Research/blob/master/presentations/2019_02_BlueHatIL/2019_01% 20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and% 20shifts%20in%20software%20vulnerability%20mitigation.pdf

    work page 2019

  80. [80]

    DataSentinel: A Game-Theoretic Detection of Prompt Injection Attacks

    Marius Momeu, Alexander J. Gaidis, Jasper v. d. Heidt, and Vasileios P. Kemerlis. 2025. IUBIK: Isolating User Bytes in Commodity Operating System Kernels via Memory Tagging Extensions. InIEEE Symposium on Security and Privacy, SP 2025, San Francisco, CA, USA, May 12-15, 2025, Marina Blanton, William Enck, and Cristina Nita-Rotaru (Eds.). IEEE, 867–885.htt...

    work page doi:10.1109/sp61157.2025.00135 2025

Showing first 80 references.