Derandomizing the Location of Security-Critical Kernel Objects in the Linux Kernel

Derandomizing the Location of Security-Critical Kernel Objects in the Linux Kernel

Speakers: Lukas Maar, PhD Candidate, Graz University of Technology; Lukas Giner, Postdoctoral Researcher, Graz University of Technology

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=nOXwh8BfRDo

Reading Time: ~7 minutes

Type: Briefing

TL;DR

Researchers Lukas Maar and Lukas Giner from Graz University of Technology present a TLB timing side-channel attack that defeats KASLR (Kernel Address Space Layout Randomization) by revealing the precise locations of security-critical kernel objects — pipe buffers, message-message objects, page tables, and the kernel stack — without requiring any kernel vulnerability. Combined with an existing exploit primitive (the "unlink" write), the technique converts a limited capability into a fully arbitrary kernel read/write primitive, demonstrated live on the latest Linux kernel with a privilege escalation to root.

Introduction

Kernel exploitation on Linux typically follows a well-worn path: find a vulnerability that grants a limited overwrite capability, convert that into a read primitive, use the read to defeat KASLR and locate target objects, then write attacker-controlled values to achieve privilege escalation. Each conversion step is fragile and prone to race conditions, kernel state corruption, and eventual crashes — all of which leave forensic evidence in kernel logs and can trigger incident investigations.

The Graz researchers attack a different layer of this problem. Rather than improving the fragile conversion steps, they use a microarchitectural side channel — TLB (Translation Lookaside Buffer) timing — to directly and reliably locate target kernel objects before any exploit primitive is exercised. This removes the need for a read primitive entirely, turns the "where to write" challenge from a probabilistic guessing game into a deterministic lookup, and dramatically improves both the reliability and stealth of kernel exploitation.

The TLB Side Channel: How It Works

▶ Watch: TLB Architecture and Timing (06:00)

The TLB is the CPU's cache for virtual-to-physical address translations. On Intel CPUs, it has 256 sets with 6 ways each, indexed by XOR-ing two subsets of the virtual address bits. A TLB hit (translation cached) takes 1–2 cycles; a TLB miss requires a page table walk of 4–5 memory accesses. The timing difference is measurable from unprivileged user space.

The attack uses the prefetch instruction, which initiates a TLB access without performing an architectural memory read — meaning user-space code can probe a kernel virtual address without receiving a page fault, yet still observe whether that address's translation is cached in the TLB. By reading a high-resolution cycle timer before and after the prefetch, an attacker can classify any virtual address as:

• Unmapped (no translation exists — cannot be in TLB)
• Mapped but not recently accessed (slow prefetch — TLB miss)
• Mapped and recently accessed (fast prefetch — TLB hit)

To reset a cached entry and re-probe, the attacker fills the relevant TLB set with "eviction set" addresses — addresses that map to the same TLB set as the target — expelling the target's translation.

This primitive provides two distinct capabilities: (1) identifying whether a virtual address range is mapped at all (to locate KASLR-randomized kernel regions), and (2) identifying whether a specific mapped address was recently accessed (to locate individual kernel objects accessed via syscalls).

Amplifying the Signal: Defenses as Attack Enablers

▶ Watch: Defenses That Change Memory Mappings (12:01)

A fundamental limitation of TLB-based leakage is granularity: most kernel memory is mapped with 2-megabyte huge pages, meaning the TLB leaks 2 MB-aligned locations, not individual 4 KB objects. The researchers resolve this by observing that several Linux kernel defenses have a side effect of splitting huge pages into 4 KB mappings:

1. CONFIG_VMAP_STACK — moves kernel stacks from the direct physical map (huge pages) to vmalloc space (4 KB pages). Enabling this defense makes the kernel stack individually locatable.
2. SLAB_VIRTUAL — virtualizes the entire kernel SLAB heap onto 4 KB mappings, making every heap object individually resolvable via TLB probing.
3. Strict module memory permissions — when a kernel module's code segment is marked read-only and non-writable, the kernel must split the 2 MB page containing the module into 4 KB pages to set per-page permissions. This split propagates to adjacent objects on the same huge page, including attacker-interesting objects like pipe buffers and message-message structures.

An unprivileged user can load kernel modules indirectly by triggering kernel functionality that autoloads modules not yet present in memory, causing the page-splitting side effect without any special privilege.

Locating Target Objects via Syscall-Induced TLB Patterns

▶ Watch: Syscall TLB Pattern Extraction (16:01)

Once 4 KB resolution is available, the researchers locate individual objects by correlating the TLB access patterns of specific syscalls. Each syscall that touches a target object loads a predictable set of kernel pages into the TLB, creating a characteristic "fingerprint." For example:

• msgrcv (message receive) accesses the IPC namespace, the message queue object, and the target message-message object in sequence — three distinct TLB loads.
• read on a pipe file descriptor accesses the pipe buffer object.
• Any invalid syscall touches the current thread's kernel stack page.
• Page-table walk syscalls load page table entries.

By calling the same syscall twice with identifiers that differ by one object (e.g., message 0 and message 1), and taking the intersection of their respective TLB footprints, the researchers isolate the single page on which both objects reside. A "control" syscall call with a known-different object then eliminates remaining ambiguity. The full msgrcv syscall touches approximately 900 TLB entries across multiple levels, but the set-intersection algorithm reduces this to the single target page.

After locating the page, the researchers apply a SLAB timing side channel to massage the Linux allocator so that the target page is densely populated with attacker-controlled objects of uniform type, making every offset on the page a predictable target.

The attack was evaluated across Linux kernel versions 5.15, 6.5, and 6.8, on multiple Intel and AMD CPUs, with success rates close to 100% after allocator massaging.

From Location Disclosure to Arbitrary Read/Write

▶ Watch: Live Privilege Escalation Demo (24:02)

With the exact page location of a target object known, the researchers demonstrate how to convert a constrained "unlink" exploit primitive (a doubly-linked-list unlink that writes two controlled values to two controlled addresses — as used in the "Bad Binder" exploit and others) into a full arbitrary read/write primitive using pipe buffers.

A pipe_buffer kernel object holds a page pointer referencing the physical-backed page where pipe data is stored. After locating a SLAB page densely filled with pipe buffer objects, the unlink primitive overwrites the page pointer in pipe_buffer[0] to point back to the SLAB page itself (a self-referential pointer). Writing to pipe buffer 0 then overwrites the metadata of pipe buffer 1. In particular, the page pointer in pipe buffer 1 is overwritten with an arbitrary target page address. A subsequent legal read syscall on pipe buffer 1's file descriptor reads from whatever physical page was specified — providing arbitrary kernel read. A legal write syscall provides arbitrary kernel write.

This primitive is then used to overwrite the uid and gid fields of the current cred structure to zero, achieving root. In the live demo on stage, the exploit completed in seconds and returned a root shell — running on the kernel version compiled the previous evening.

Mitigations

▶ Watch: Mitigations (26:04)

The primary software mitigation is KPTI (Kernel Page Table Isolation), originally introduced for Meltdown and Spectre. KPTI unmaps all kernel mappings from the page tables visible in user space, preventing the prefetch instruction from accessing TLB entries for kernel addresses. The overhead of the user/kernel transition (a TLB flush on each system call boundary) is why KPTI is no longer enabled by default on modern hardware that is not Meltdown-vulnerable.

The more promising long-term solution is Intel LAS (Linear Address Space Separation), a hardware mechanism that checks the most significant bit of a virtual address and blocks the TLB access entirely for kernel addresses when the processor is running in user mode — stopping the side channel before it reaches the TLB translation stage, with no context-switch overhead.

Notable Quotes

"We can perform reliable and stable kernel exploitation — the key word here is reliable and stable, because that is not always the case."

— Lukas Maar, 00:00

"Defenses can have unintended side effects that decrease security. They hopefully also increase it somewhere else — but that's something to be mindful of."

— Lukas Giner, 26:04

"An arbitrary read/write primitive is, in the Linux kernel, basically god mode."

— Lukas Maar, 04:00

"We adapted the PoC to the latest kernel version yesterday evening. Nothing is going to go wrong."

— Lukas Giner (before live demo), 24:02

Key Takeaways

• KASLR is bypassable without a kernel vulnerability. The TLB side channel is exploitable from unprivileged user space on unpatched hardware, using only standard syscalls and the prefetch instruction.
• Security defenses can weaken isolation elsewhere. CONFIG_VMAP_STACK, SLAB_VIRTUAL, and strict module memory permissions all change kernel memory layout in ways that amplify the TLB side channel from 2 MB to 4 KB granularity.
• Re-enabling KPTI is the software fix. At the cost of system call performance, KPTI eliminates the side channel by removing kernel TLB entries from user-space page tables.
• Intel LAS is the hardware answer. Future CPUs with Linear Address Space Separation hardware will block the attack at the architectural level with no performance penalty.
• Reliable exploitation changes the threat model. When a limited exploit primitive can be deterministically converted to arbitrary read/write without kernel crashes or log artifacts, the window for forensic detection narrows significantly.

Slides PDF: Not available for this session.