Kernel Exploitation

# Kernel Heap Techniques — SLUB, Cross-Cache, msg_msg, pipe_buffer, sk_buff

> **AI LOAD INSTRUCTION**: Load this when exploiting kernel heap vulnerabilities. Covers SLUB allocator internals, object lifecycle, cross-cache attack methodology, and exploitation of specific kernel structures (msg_msg, pipe_buffer, sk_buff, setxattr). Assumes [SKILL.md](./SKILL.md) is loaded for kernel exploitation model and [KERNEL_MITIGATION_BYPASS.md](./KERNEL_MITIGATION_BYPASS.md) for mitigation context.

---

## 1. SLUB ALLOCATOR OVERVIEW

Linux kernel uses SLUB (Unqueued Slab Allocator) for small kernel object allocation.

### Key Concepts

| Concept | Description |
|---|---|
| Slab | Contiguous pages holding objects of the same size |
| Cache | Named pool for specific object types (e.g., `kmalloc-64`, `task_struct`) |
| Freelist | Per-CPU linked list of free objects within a slab |
| Partial list | Per-node list of slabs with some free objects |
| Generic caches | `kmalloc-{32,64,96,128,192,256,512,...}` for generic allocations |

### Object Layout in Slab

```
┌─────────┬─────────┬─────────┬─────────┐
│ Object0 │ Object1 │ Object2 │ Object3 │  ← one slab page
└─────────┴─────────┴─────────┴─────────┘
  FP→Obj2   FP→Obj3   FP→NULL   (allocated)

FP = freelist pointer (stored at object start or random offset)
```

### Freelist Randomization (SLAB_FREELIST_RANDOM)

Object allocation order within a slab is randomized. Affects heap spray reliability.

### Freelist Hardening (SLAB_FREELIST_HARDENED)

```c
// Freelist pointer is XOR'd with a random value and the address
// Similar to glibc safe-linking
stored_fp = ptr ^ random_value ^ &stored_fp
```

---

## 2. SLAB OBJECT LIFECYCLE

```
kmalloc(size, GFP_KERNEL)
  → Check per-CPU freelist (fastest)
  → Check per-CPU partial list
  → Check per-node partial list
  → Allocate new slab pages

kfree(ptr)
  → Return to per-CPU freelist (if same CPU and slab)
  → Return to per-node partial list
  → Free slab pages (if all objects freed)
```

### Heap Spray Strategy

1. Identify target slab cache (based on object size)
2. Drain existing free objects (spray dummy allocations)
3. Trigger vulnerability (UAF/OOB on target object)
4. Spray replacement objects (same size → land in freed slot)

---

## 3. CROSS-CACHE ATTACK

**Exploit UAF across different slab caches by forcing page-level reuse.**

### Why Cross-Cache?

Many kernel objects have dedicated caches (e.g., `struct cred` in `cred_jar`, not `kmalloc-192`). Cannot spray `kmalloc-192` to replace a freed `cred` object. Cross-cache forces the slab pages to be returned to the page allocator and reallocated to a different cache.

### Methodology

```
1. Spray target objects to fill slabs        [Target slab: all allocated]
2. Free target objects (leave one page worth) [Target slab: one partial page]
3. Free ALL objects in that page              [Page returned to page allocator]
4. Spray attacker objects (different cache)   [Page reallocated to attacker cache]
5. UAF on target object now aliases attacker object on same physical page
```

### Page-Level UAF Steps

```c
// Phase 1: Fill target cache so new slabs are allocated
for (int i = 0; i < SPRAY_COUNT; i++)
    target_alloc();  // allocate target objects

// Phase 2: Create hole pattern (free specific objects to isolate one slab page)
// Free all objects in one specific slab page
for (int i = PAGE_START; i < PAGE_START + OBJS_PER_PAGE; i++)
    target_free(i);

// Phase 3: Victim object freed (UAF) — was on the now-freed page
trigger_uaf();

// Phase 4: Page is returned to buddy allocator
// Phase 5: Reallocate page into attacker's cache
for (int i = 0; i < SPRAY_COUNT; i++)
    attacker_alloc();  // e.g., msgsnd() for msg_msg
```

---

## 4. msg_msg EXPLOITATION

`struct msg_msg` is allocated via `msgsnd()` and freed via `msgrcv()`. Highly flexible size (48-byte header + arbitrary data).

### Structure Layout

```c
struct msg_msg {
    struct list_head m_list;  // 0x00: prev/next pointers
    long m_typ