Overview
This series explains how Linux KFENCE’s low-overhead sampling changes an allocation’s ownership, placement, tagging, reuse, and error-handling guarantees. It contrasts ordinary slab segregation with KFENCE’s guarded shared pool, traces the lifecycle and Fence2Pwn’s calibration, pool shaping, and FIFO rotation, then weighs experiments, deployment conditions, and mitigations. The study reports conditional UAF-based cross-cache-style overlap and path-specific KASAN or tagging gaps in evaluated configurations, including a real vulnerability reaching allocator control—not a universal exploit or end-to-end privilege escalation. Readers gain a configuration-sensitive basis for balancing production bug detection against kernel-exploitation exposure.
Learning outcomes
- KFENCE’s low overhead comes from sampling and a separate guarded pool, not continuous coverage of every allocation.
- In the evaluated configurations, KFENCE-served objects did not inherit all ordinary slab segregation or KASAN and tagging behavior.
- Fence2Pwn combines observable sampling, shared-slot reuse, FIFO rotation, and a known UAF to enable conditional cross-cache-style overlap.
- Experiments show repeatable overlap in selected environments, not a universal success rate or an end-to-end privilege escalation.
- Disabling active sampling reduces the studied exposure but sacrifices production bug detection; durable fixes must secure the whole path.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
What is Fence2Pwn?
Fence2Pwn is a study and technique showing how, with KFENCE enabled and a known UAF, allocation-path differences can enable conditional cross-cache-style object overlap.
Why does KFENCE’s allocation path matter for security?
KFENCE’s sampled pool can use different placement, tagging, reuse, and fault-handling rules from ordinary slab allocation, so diagnostic value does not guarantee identical heap-hardening protections.
Does Fence2Pwn prove a Linux privilege escalation?
No. The study reports controlled overlap and a real CVE reaching allocator control, but it does not claim an end-to-end privilege escalation or a universal result.
When is a Linux system relevant to Fence2Pwn?
A Linux system is relevant when KFENCE is enabled and active, with pool capacity and a nonzero sampling interval, and an applicable UAF and unprivileged kernel attack surface also exist.