Heap Feng Shui — Precisely Shaping Heap Memory Layout for Exploitation

TL;DR — Heap feng shui is the meta-technique of coercing a non-deterministic heap allocator into the order, adjacency, and reuse pattern the attacker wants, turning a corruption primitive like UAF/overflow into reliable code execution. It's a core weapon in both userspace (Scudo, libmalloc) and the kernel (SLUB, kalloc), and the starting point for any study of modern mitigations (MTE, PAC, freelist randomization, SLAB_VIRTUAL, kalloc_type).

1. The core idea

To exploit a heap bug (UAF, heap overflow, double-free, type confusion, …), a specific object has to land at a specific location in memory. But a normal heap allocator is non-deterministic, for several reasons:

• Freelist fragmentation — the distribution of free chunks depends on the prior alloc/free history
• Thread caches (tcache, per-CPU cache, magazine) — per-thread/per-CPU LIFO caches split same-size objects across locations
• Randomization mitigations — Scudo's chunk-header checksum, SLUB's randomized freelist, libmalloc's nano/scalable zone randomization
• Allocator-internal policy — size-class rounding, region/slab/zone boundaries, large-allocation branches

Heap feng shui tames that non-determinism with a crafted sequence of allocations and frees, driving the heap into a deterministic state. The name comes from feng shui (風水), the art of spatial arrangement, and was coined in Alexander Sotirov's 2007 Black Hat USA paper "Heap Feng Shui in JavaScript."

2. History and evolution

Recent direction (2024–2026) — it boils down to three threads.

1. Page-level feng shui — beyond slab/zone, the DirtyPagetable / Dirty Pagedirectory (CVE-2024-1086) family reuses a buddy-returned page as a page table (PTE) (arbitrary PTE manipulation → physical-memory R/W → kernel patching), now a powerful go-to path. That said, CROSS-X notes page-level reuse is relatively rare and may require extra privileges/conditions — it isn't the endpoint of every cross-cache.
2. Cross-cache generalization — SLUBStick (99%+ success) and CROSS-X (ACM CCS '25) pushed cross-cache reliability from the old ~40% up to production level.
3. The hardware-tagging arms race — Apple MIE (2025, iPhone 17/A19) applies EMTE always-on across the kernel + 70+ userland processes, attacking feng shui's "silent corruption" premise head-on. Yet the same year's Mali-GPU CVE-2025-0072 bypassed MTE — defenses raise the cost but don't end the game.

3. How it works

The overall flow runs in seven stages.

1. Defragmentation — fill holes to compact the heap
2. Hole creation — deliberately free a target-sized slot
3. Victim allocation — place the vulnerable object at the exact spot
4. Adjacent placement — place an attacker-controlled object in the neighboring slot
5. Trigger primitive — fire the UAF / overflow / double-free
6. Corruption — overwrite metadata / vtable / function pointer
7. Arbitrary R/W or RIP control — read/write anywhere or hijack control flow

3.1 The four core building blocks

1. Massage — mass-allocate same-size objects to drain the freelist and force a fresh slab/region/zone
2. Punch hole — free exactly the intended slot so the next allocation lands there
3. Pin victim — control timing and size so the vulnerable object falls into the hole
4. Place attacker chunk adjacent — put attacker-controlled, payload-ready data in the neighboring slot

4. Heap Spraying vs Heap Feng Shui

Real exploits usually combine the two — feng shui builds the corruption, then a spray stabilizes the RIP jump target.

5. Allocators by platform

5.1 At a glance: Android vs iOS

5.2 Android Scudo (userspace)

From Android 11, the default userspace allocator changed to Scudo.

• Primary allocator: region-based, using a size-class map that varies by version/config (on Android 14, the WOOT '24 analysis lists primary class IDs 1–32 — "exactly 16" is version-dependent). Each region's freelist runs through per-thread caches (TransferBatch) and slot randomization, so it's more involved than a plain LIFO.
• Secondary allocator: large allocations (64 KB+ by default) get their own guard-page-wrapped mmap region.
• Chunk header: header integrity is verified with a CRC32-based checksum incorporating a global secret/cookie — abort immediately on corruption.
• Quarantine: freed chunks are briefly quarantined to block immediate UAF reuse.
• MTE integration: on tag-enabled devices, a tag mismatch raises SIGSEGV.

WOOT '24 bypass summary

Technique 1 — abuse Scudo's internal cache mechanism to steer a chunk near an arbitrary address (since patched).

Technique 2 — leverage the secondary allocator's large-chunk handling — a structural issue, hard to patch.

5.3 Linux SLUB (Android kernel)

The Android kernel uses Linux SLUB.

• General allocations go to kmalloc-* caches (8 B – 8 KB, powers of two plus the 96 B/192 B exceptions; recently kmalloc-cg-* is split out).
• Only objects in the same size-class cache sit adjacent → the key is finding a useful kernel object of the same size as the target.
• A three-level structure: per-CPU active slab + partial list + node partial.
• CONFIG_SLAB_FREELIST_HARDENED — obfuscates freelist pointers as ptr XOR random XOR &ptr.
• CONFIG_SLAB_FREELIST_RANDOM — randomizes slot order within a slab (once, at slab creation).
• CONFIG_RANDOM_KMALLOC_CACHES — hash-picks one of 16 sibling caches per size (Linux 6.6+, optional — may be off on GKI/specific devices).
• SLAB_VIRTUAL (experimental) — isolates slab pages into a virtual-address-only pool to block cross-cache reuse.

5.4 iOS libmalloc (userspace)

The default userspace allocator on iOS/macOS.

• Nanozone: dedicated to tiny allocations ≤256 B. 16 B granularity, per-CPU magazine structure.
• Scalable zone (tiny/small/large):
  • tiny: ≤1 KB, 16 B quantization
  • small: ≤15 KB (or 32 KB on 16 K pages), 512 B quantization
  • large: above that, direct vm_allocate
• Pointer Authentication (arm64e): zone freelist pointers are PAC-signed with the IB key; forgery faults.
• Magazine secret / cookie: XOR protection on chunk metadata.
• Guard malloc / libgmalloc: a debugging mode that isolates every allocation to a page (disabled in production).

5.5 XNU zalloc / kalloc_type (iOS kernel)

The iOS kernel heap is structured differently from SLUB, so the feng shui strategy differs too.

• Zone: a free list pooling allocations of the same element size and the same "purpose." Hundreds of named zones exist (kalloc.*, ipc.ports, OSData, …).
• kalloc heap separation (iOS 14+): purpose-specific heaps like KHEAP_DEFAULT, KHEAP_DATA_BUFFERS, KHEAP_KEXT keep data and pointers out of the same zone.
• kalloc_type (iOS 15+): bucketed type isolation that places type signatures into randomized buckets. Multiple types can share a bucket, but it sharply shrinks the pool of UAF realloc candidates (types that could land in the same slot), making type-confusion exploitation much harder — it does not hard-block all type confusion.
• Zone require / zone_id check: verifies zone identity on free.
• Zone GC: reclaims empty pages, making cross-zone reuse harder.
• PPL → SPTM/TXM (A15+): a separate monitor validates page-table entries themselves, so an R/W gadget can't patch kernel text.
• Memory Integrity Enforcement (MIE) · Enhanced MTE (A19/M5+, 2025): always-on EMTE that blocks memory-safety violations in hardware — the newest defense, breaking feng shui's premise of "silent corruption."

Android SLUB vs iOS zalloc in one line

SLUB is "everything in a size class goes into one pool → a game of finding a useful same-size object." iOS, post-kalloc_type, is "same-size objects in different type buckets rarely mix (probabilistic, since bucketing is randomized) → a game of finding what's useful within the same bucket."

6. A catalog of useful kernel/IPC objects

Exploit reliability comes down to "what object can you place in the adjacent slot at the moment of corruption."

Android (Linux SLUB)

iOS (XNU zalloc)

7. Cross-cache / cross-zone attacks

When there's no useful object you can place in the same cache/zone, recycle the slab/zone page itself into a different cache.

• Android: to target a victim trapped in kmalloc-cg-* or a dedicated cache, free all the slab pages in that cache so they return to the buddy allocator, then induce another cache (e.g. msg_msg) to grab those pages.
  • Key tools: racing pcpu_alloc, kvfree, __free_pages_ok.
  • Defenses: SLAB_VIRTUAL, kvmalloc separation, page tagging.
• iOS: since kalloc_type, only the same type tends to share a zone, so cross-zone is harder. Instead, "zone-level feng shui" research uses zone garbage collection to get a page reassigned to a different zone.
  • PAC and SPTM additionally block cross-zone fake-pointer attacks.

8. Real-world cases

9. Modern defenses, organized

10. Automation / research tooling

• Maze (USENIX Security '21) — symbolic-execution-based automatic heap-layout synthesis. Input an exploit scenario → output an alloc/free sequence.
• SLUBStick (USENIX Security '24) — an automation framework for Linux SLUB cross-cache attacks.
• Syzkaller + KASAN — discover trigger sequences + track heap state.
• kasld / kbase finder — automate KASLR-bypass info leaks.
• On iOS: KTRR/SPTM bypass research, panic-log diffing — few public tools, so writing your own PoC is the norm.
• MTE-aware fuzzing (HWASAN, scudo_standalone) — use tag mismatches as a corner case.

11. References

Foundations / history

• Heap Feng Shui in JavaScript (Black Hat 2007, Alexander Sotirov)
• Pool Feng Shui — Windows kernel (Chen, 2010)
• Maze: Towards Automated Heap Feng Shui (USENIX Security '21)

Android / Linux SLUB

• Linux kernel heap feng shui in 2022 (duasynt)
• Exploiting Android's Hardened Memory Allocator (WOOT '24)
• Attacking Android Binder: CVE-2023-20938 (Google Android Offensive Security)
• SLUBStick (USENIX Security '24)
• CROSS-X: Generalized and Stable Cross-Cache Attack on the Linux Kernel (ACM CCS '25)
• Flipping Pages — nf_tables CVE-2024-1086 (Dirty Pagedirectory)
• Dirty Pagetable — page-table-based kernel exploitation
• Bypassing MTE with CVE-2025-0072 (GitHub Security Lab)
• Drammer: Flip Feng Shui Goes Mobile (VUSec)

iOS / XNU

• Attacking the XNU Kernel in El Capitan (Mandt, BH EU 2015)
• iOS kernel heap revisited (Project Zero)
• Towards the next generation of XNU memory safety — kalloc_type (Apple Security)
• Operation Triangulation: CVE-2023-32434 deep dive (Kaspersky SAS '23)
• Memory Integrity Enforcement — Apple's memory-safety strategy (Apple Security, 2025)