Skip to content

Use-After-Free Landscape: Temporal vs Spatial, kCFI, and the Proven-by-Construction Story

The 2024-2026 industry picture on temporal memory safety, kernel mitigations, and the convergence of UAF defences.

memory-safety industry

§1 Provenance

§2 Claim

Memory-safety CVEs split into two disjoint categories:

  • Spatial memory safety bugs — out-of-bounds reads, out-of-bounds writes, buffer overflows. CWE-787 (out-of-bounds write), CWE-125 (out-of-bounds read), CWE-119 (improper restriction).
  • Temporal memory safety bugs — use-after-free, double-free, use-after-realloc. CWE-416 (use after free), CWE-415 (double free), CWE-672 (use of expired resource).

Spatial bugs are easier to defend against in C/C++. Stack canaries, ASLR, fortified memcpy, bounds checking, AddressSanitizer in CI — all reduce exploitability. The 2024-2025 record shows that spatial memory-safety zero-days are increasingly rare in modern hardened software.

Temporal bugs are much harder. The C/C++ heap allocator has limited information about pointer liveness. Dangling pointers after free() are valid C — the bug is in the use, not the free. Hardware mitigations help (Intel MPX failed; CHERI capabilities do work but require new silicon; MTE on ARM is partial). Software mitigations include:

  • Hardened allocators: Scudo (Android), GWP-ASan (Chrome), PartitionAlloc, mimalloc-secure. Reduce reliability of exploitation but don’t prevent the bug.
  • Quarantine pools: delay reuse of freed memory until likely-stale pointers have been cleared.
  • GC-style memory: never reuse memory while a pointer to it might be live. This is what JVM, V8, Go, Mochi do — and is the only fully-effective software-level UAF defence in C-like languages.
  • Memory tagging: MTE on ARMv8.5+, HWASan in software. Probabilistic detection; not prevention.
  • Control-flow integrity: kCFI in Linux, Intel CET, ARM BTI. Reduces what an attacker can do with a UAF, doesn’t prevent the UAF itself.

The dominance of CWE-416 in CVE rankings reflects this asymmetry — temporal bugs are now the dominant memory-safety bug class in modern hardened C/C++ codebases.

§3 Scope and Limits

Industry data 2024-2025:

  • VulnCheck records ~200 memory-safety KEVs in 2024 — a high. The trend in absolute terms is up, not down, despite the percentage trend going down.
  • CWE-416 is at or near the top of the CWE Top 25 every year 2022-2025.
  • Chromium attributes more than a third of high-severity bugs to CWE-416 alone.
  • 2024-2025 production UAF CVEs include CVE-2024-1086 (Linux netfilter, leveraged for kernel privilege escalation in the wild), CVE-2025-49844 (Redis Lua RCE), CVE-2025-49761 (Windows kernel SYSTEM), CVE-2025-8292 (Chrome Media Stream).
  • The Linux kernel deploys kCFI, kASLR, kPGT (pointer guard tables — being explored), kmsan (kernel-level MemorySanitizer for CI), CONFIG_INIT_ON_FREE (zero memory on free, blunting some UAF exploitation), CONFIG_INIT_ON_ALLOC, GFP_USERCOPY hardening, slab freelist hardening.

Limits. None of the software-only defences in C/C++ prevent UAF; they only make it harder to exploit. The only “proven-by-construction” UAF defences in production are:

  • Tracing GC (JVM, V8, Go, Mochi, Erlang, etc.).
  • Reference counting (Swift, Python, sometimes Rust Rc/Arc).
  • Region-based memory (Cyclone, parts of Rust via lifetimes).
  • CHERI capability revocation in hardware.

Of these, only tracing GC, refcounting, and Rust’s borrow check are mainstream. CHERI is shipping but limited to specialist deployments.

§4 May 2026 Status

Temporal safety is the unresolved frontier in C/C++. Spatial safety is largely a solved problem (ASan/MSan/UBSan + Spanification-style hardening); temporal safety remains hard. The 2024-2025 production-CVE record confirms this: most actively-exploited memory-safety zero-days in 2024-2025 are temporal, not spatial.

The “proven-by-construction” story is winning. Languages with GC or borrow-checking eliminate UAF as a category. Rust’s “no UAF in safe Rust” guarantee, plus the V8 / JVM / Go / Python reality that GC’d languages have no UAF, is the headline argument. The 2025 NSA-CISA CSI cites this directly.

Mitigations are deployed at scale but probabilistic. kCFI is in upstream Linux; Scudo is Android’s default allocator; ARM MTE is shipping on Pixel 8 and later. Production hardened C/C++ has dramatically lower exploit reliability than 2010-era C/C++ — but the bugs remain present.

Hardware solutions are emerging. CHERI is shipping (Morello, CHERIoT, Microsoft CHERIoT-Ibex). ARM MTE is shipping. These offer hardware-enforced temporal safety, but only on specific silicon.

§5 Cost

The aggregate cost of temporal-memory-safety mitigation in C/C++ is enormous and ongoing: every Linux kernel hardening feature, every allocator hardening, every browser sandbox, every fuzzing campaign. Hundreds of engineer-years per year industry-wide. The CVE bounty payouts alone — Chrome’s 41K−per−high−severity,Microsoft′s41K-per-high-severity, Microsoft's 20K-200KMSRCbounties,AppleSecurityBountyupto200K MSRC bounties, Apple Security Bounty up to 1M — quantify the market value of UAF defences.

Memory-safe-language adoption is competitive on cost. Google’s Android trajectory (76% → 20% memory-safety bugs over 6 years) shows that redirecting new code to memory-safe languages costs less per CVE prevented than continuing to harden C/C++.

§6 Mochi Adaptation Note

This is the single most-relevant industry topic for Mochi’s Cell design.

  • Mochi’s generation tags are a temporal-safety mechanism. The 12-bit generation field on every Cell is exactly the kind of revocation token CHERI provides in hardware — a way to say “this handle is stale because the underlying object has been reclaimed”. MEP-41 should explicitly frame the generation tag as Mochi’s UAF defence and cite the industry data showing why UAF is the dominant bug class.
  • The “proven-by-construction” story is Mochi’s strongest claim. Mochi-source code cannot produce a use-after-free, because (a) Cell handles are checked on every dereference and (b) the planned mark-sweep ensures Cells become unreachable before their generation is reused. MEP-41 should make this claim explicitly.
  • The CHERI parallel is the right architectural framing. Mochi’s Cell is a software CHERI-like capability with a revocation tag (generation). CHERIoT is the hardware analogue; Mochi is the language-runtime analogue. MEP-41 should call out the parallel (see also verification/10).
  • The 12-bit generation choice has direct industry analogue. ARM MTE uses 4-bit tags; CHERI uses larger object-identity fields. Mochi’s 12 bits sits comfortably in the middle — long enough to make ABA-style stale-handle reuse extremely improbable (1 in 4096 reuse collision rate, with practical sequences much lower because of mark-sweep ordering). MEP-41 should justify the 12-bit choice against this comparison set.
  • The industry data refutes “just harden C/C++”. Stenberg, Chrome, Microsoft, Android all show that mitigation is partial. The only way to prevent UAF in a language is by design. MEP-41 can use this to justify Mochi’s existence.
  • kCFI / kMSAN / Scudo / MTE are defence-in-depth, not prevention. Mochi gets to claim prevention. MEP-41 should articulate the distinction clearly.

§7 Open Questions for MEP-41

  1. Should MEP-41 explicitly state “Mochi prevents use-after-free by construction” as a top-line claim? It is true and the most-defensible claim Mochi can make.
  2. Should MEP-41 justify the 12-bit generation tag against the ARM MTE 4-bit choice and the CHERI larger-field choice? Doing so makes the design legible to security architects.
  3. Should MEP-41 commit to ABA-style stale-handle re-use analysis — i.e., publish a worst-case scenario for generation-tag collisions and the mitigation (mark-sweep ordering)?
  4. Should MEP-41 reference the 2024 IEEE S&P “Full Spatial and Temporal Memory Safety for C” paper as the baseline of difficulty that Mochi avoids by virtue of being a new language?
  5. CHERI is shipping in hardware. Should MEP-41 commit to a “Mochi-on-CHERI” exploration in a future MEP, anticipating that hardware capability machines may become the natural deployment target for software capability designs like Mochi’s Cell?