Hands Off and Putting SLAB/SLUB Feng Shui in a Blackbox

## Overview

Jesse Chan (PhD student, Penn State; exploitation/vulnerability analysis focus) presented techniques for exploiting kernel heap memory corruption vulnerabilities in Linux via SLAB/SLUB allocator manipulation. Collaborators include advisor Shi (Penn State) and Jimmy (security research director, JD.com). Kernel heap exploitation is fundamentally different from userspace heap exploits due to asynchronicity, multitasking, code base scale, and system call interdependencies. The talk focuses on identifying exploitable kernel objects and automating the process of crafting reliable exploits for use-after-free and buffer overflow bugs affecting the SLAB/SLUB allocator—Linux's primary memory allocator managing dynamic kernel memory via object-caching strategy. Current exploitation approaches require manual identification of victim objects, spray objects, and system call sequences, making exploit development time-consuming and error-prone. The research presents an automated framework using static analysis, reachability analysis, and kernel fuzzing to systematically identify useful kernel objects and corresponding system calls for reliable exploit construction.

## SLAB/SLUB Architecture and Exploitation Primitives

**Memory Organization and Allocation**: Linux kernel dynamic memory is organized into slab caches (continuous pages divided into fixed-size slots). Each slab cache holds objects of similar size or type. Free slots are organized in a linked list with a head pointer for LIFO (Last-In-First-Out) allocation. Allocation retrieves a slot from the free list (head pointer advances). De-allocation recycles slots back to the head (head pointer updated). This design achieves cache locality and deterministic allocation patterns exploitable via heap spraying.

**Use-After-Free (UAF) Exploitation**: Three-step attack: (1) Vulnerable object is freed; its slot is recycled; dangling pointer created but not notified to attacker code; (2) Attacker performs heap spray—allocates new objects to the same slot as the freed vulnerable object; overwrites its function pointer with malicious address; (3) When the dangling pointer dereferences the function pointer, hijacked code executes. Prerequisite: attacker must identify which objects can be allocated to the target slot.

**Slab Buffer Overflow Exploitation**: Three-step attack: (1) Allocate victim object adjacent to vulnerable object; victim contains exploitable function pointer; (2) Trigger security bug (buffer overflow in vulnerable object) to corrupt victim object's memory layout, specifically overwriting its function pointer to malicious address; (3) Dereference overwritten function pointer to hijack control flow. Key challenge: victim and vulnerable objects must occupy adjacent slots in the slab cache.

**Identifying Exploitable Objects**: UAF and overflow exploits depend on finding three object types: (1) Victim object—contains function/data pointers attackers can overwrite or dereference; (2) Vulnerable object—contains the security bug (use-after-free, buffer overflow) attackers can trigger; (3) Spray object—controllable content (allocated via copy_from_user) attackers can inject malicious payloads into. All three must be similar size or same slab cache type for reliable co-location.

## Automated Exploit Framework and Kernel-Specific Challenges

**Kernel Challenges vs. Userspace**: Kernel heap exploitation is harder than userspace for three reasons: (1) Code scale—Linux kernel has >300 system calls, hundreds of thousands of objects after boot, ~1 million kernel pointers; static solutions that work for userspace don't scale; (2) Asynchronicity—RCU (Read-Copy-Update) mechanism registers callbacks that defer dereferencing; attackers may lose track of where function pointers are registered after the grace period; (3) Multitasking—user processes, kernel threads, hardware interrupts trigger concurrent execution and modify objects simultaneously, generating noise in heap layout.

**Static Analysis and Reachability**: The framework uses static analysis on kernel source to: (1) identify useful objects (victim/spray types) with function pointers or controllable data; (2) identify allocation/dereference sites for these objects; (3) build call graphs tracing backward from sites to entry points; (4) compute which system calls can reach these sites via call graph reachability. Example: `setsockopt()` system call can reach memory allocation in `ip_mc_join_group()` via call chain—so `setsockopt()` is a candidate for triggering the vulnerable object's allocation.

**Kernel Fuzzing Validation**: Static analysis produces candidate system calls and arguments; kernel fuzzing empirically validates that these calls actually allocate/deallocate objects as predicted. Fuzzing eliminates false positives from static analysis and captures runtime behavior (asynchronicity, multitasking) that static analysis cannot fully model. Fuzzing also explores system call combinations to discover sequences that reliably achieve desired slab layout.

**Object Database and Automation**: The framework builds a database indexing: (1) exploitable kernel objects (victims, spray candidates) with their sizes and pointer offsets; (2) system calls that can allocate/deallocate these objects with corresponding arguments; (3) validated call sequences achieving specific slab layouts. Exploit developers query this database to find objects matching their vulnerability type, reducing manual exploit development time and improving reliability.