CHERI is one of the most influential hardware security projects of the past decade. Its idea is to add a capability mechanism to the CPU—each pointer is no longer just a memory address, but a bounded authorization token. Pointers cannot access memory out of bounds, and cannot be forged. This solves spatial safety (buffer overflows and the like). But temporal safety—use-after-free—has never been fully solved.
Use-after-free is subtle. After memory is freed and reallocated to another object, a stale pointer may still be cached—it still points to that memory, but the data there now belongs to someone else. Reading stale data is an information leak; writing to it is memory corruption. Worse: the window between free and reallocation is too short to be covered by software-level checks.
Building on years of CHERI work at the University of Cambridge, Wang, Woodruff, and colleagues propose a hardware-based capability format extension: PoisonCap. The core idea is to add a "poisoned" state marker to every capability. When memory is freed, instead of zeroing the pointer, the system marks the corresponding capability as poisoned—the pointer still exists, its bounds still exist, but any memory access through the poisoned capability triggers a hardware exception.
The question is: how does the poison propagate? PoisonCap exploits CHERI's existing capability-boundary layering. An upper-level allocator holds a capability over an entire block of memory; lower-level allocators receive restricted sub-capabilities from it. When the upper-level allocator poisons a capability, all derived capabilities held by lower-level allocators are automatically poisoned—no per-level notification needed. This guarantees the safety of an entire subtree in nested-allocator scenarios.
In terms of implementation, PoisonCap can replace Cornucopia's shadow-bitmap scheme. Freed memory is automatically zeroed, or access traps before read or write. Compared with the current state of the art, Cornucopia, PoisonCap provides stronger use-after-free protection with zero performance overhead—no added baseline latency.
Unclear points: the poisoned state requires extra hardware storage—how many additional register bits and metadata space are needed? The paper mentions "hierarchy" but does not analyze in detail the temporal overhead of poison propagation in multi-level allocator scenarios. Also, the behavior of poisoned capabilities under cache-coherence protocols is not discussed.
---
References
1. Wang, Y., Woodruff, J., Mazzinghi, A., et al. (2026). *PoisonCap: Efficient Hierarchical Temporal Safety for CHERI*. arXiv:2605.13210 [cs.AR].
2. Watson, R. N. M., et al. (2015). *CHERI: A Hybrid Capability-System Architecture for Scalable Software Compartmentalization*. IEEE S&P.
3. Woodruff, J., et al. (2024). *Cornucopia Reloaded: Efficient Temporal Memory Safety for CHERI*. ISCA.