A Detector Is Part of the Security Boundary Too
This final chapter answers the series’ opening question about Linux KFENCE and Fence2Pwn: can a production memory-safety detector remain valuable while creating a weaker allocation path? The evidence supports a qualified yes. KFENCE’s low-overhead sampling is useful by design, but in the configurations studied, the sampled path did not inherit every placement and memory-tagging property of hardened slab allocation. That is why Fence2Pwn matters, what its limits are, and why the durable answer is to secure the path rather than confuse detection with containment.
The subject is not a choice between “a good tool” and “a bad tool.” It is a composition problem. KFENCE, the slab allocator, KASAN, memory tagging, and kernel workloads each own a different part of an object’s life. The security judgment depends on whether those parts continue to agree when an allocation leaves the ordinary slab path, enters the sampled pool, is freed, and later becomes available again.
The Gap Is a Systems Property
The causal chain begins with a legitimate production constraint. A kernel memory-safety detector that checked every access with the precision of a debugging build would impose costs many production systems could not accept. KFENCE takes a different route: it samples a small number of eligible allocations, places them in a guarded pool, and relies on aggregate uptime and workload diversity to expose bugs that tests may miss. Guard pages, poison patterns, protected freed pages, and diagnostic metadata make a sampled error easier to recognize and investigate.
That design answers one question well: can the kernel obtain useful evidence about a memory error at low runtime cost? The slab allocator answers another: which object populations may share storage, and how difficult should it be to steer a freed location toward a valuable replacement? KASAN answers a third: does an access match the validity state represented by shadow memory or a memory tag? A non-fatal error policy answers a fourth: should a violation be recorded while the system continues, or should it stop the kernel?
These questions overlap, but they are not interchangeable. A protected page can isolate an object from adjacent pages without segregating the object’s class from the next object in a shared pool. A diagnostic report can identify a bad access without preventing the object from being used in a consequential context beforehand. A tag check can reject a stale pointer on one allocation path while a pointer on another path carries the catch-all value instead. A production-friendly decision can therefore be locally sensible and globally incomplete.
The ordinary slab security model relies on continuity. A request is assigned to a cache whose size and allocation category constrain its neighbors. Freelist and address protections make the available state harder to predict or manipulate. Randomization and segregation reduce the range of plausible replacements. The model does not require every collision to be impossible; it makes the path from an initial memory bug to a useful security-sensitive object narrower and less reliable.
KFENCE interrupts that continuity. The request still enters through the kernel’s normal allocation interface, but sampling can route it to a separate pool. In the study’s analysis, that pool is globally shared across object types and sizes rather than reproducing ordinary cache segregation. The object remains spatially isolated inside its page, but the pool’s next occupant is governed by a different reuse structure. The path has changed even though the caller’s interface has not.
The paper’s five weaknesses describe the consequences of that change at different stages. First, the extra bookkeeping and periodic sampler make the alternate path observable through allocation latency. Second, the shared pool changes the placement relationship between objects that ordinary caches try to keep apart. Third, KFENCE-served objects are outside the expected KASAN instrumentation or tagging behavior in the tested configurations. Fourth, poison validation can be deferred until free rather than trapping every modification immediately. Fifth, the common logging mode reports a violation while execution continues. None of these observations alone is the whole finding. Their significance comes from their composition across the object lifecycle.
Fence2Pwn uses that composition to restore a cross-cache-style reuse capability. Calibration treats periodic latency as a signal about when sampled allocation may occur. Pool shaping uses the utilization policy to estimate how many free positions remain. FIFO rotation moves a previously freed vulnerable slot toward the head of the pool. An eventual victim allocation can then reach that slot, potentially placing a different object over the memory still referenced by a UAF. An untagged KFENCE pointer removes the tag mismatch that would otherwise provide another barrier on a memory-tagged system.