Skip to content

KASLR, KPTI and Modern Kernel Defenses

Kernel address randomization, page-table isolation, and the config options that harden a Linux kernel against memory-corruption exploits — what each one stops and how to enable it.

Published on 4 min read

This is the third walkthrough in the Kernel Exploitation area, written from the defender's side. The first and second guides showed a kernel bug becoming root, and how SMEP/SMAP forced kernel ROP. Here we cover the address-hiding and isolation layers on top — KASLR, KPTI — and the config options that harden a kernel in depth.

KASLR: hide the kernel, but it is one image

KASLR loads the kernel at a random base each boot, so commit_creds and every gadget are at unknown addresses. Its defining weakness is that the kernel is a single contiguous image: one leaked kernel pointer reveals the base, and every symbol is a fixed offset from it.

One kernel leak derandomizes the entire image
leaked kernel pointerfrom a bug, /proc, or a side channel
minus known offset
kernel basethe randomized load address
plus fixed offsets
every symbol & gadgetcommit_creds, prepare_kernel_cred, gadgets
writable memorycode

So attackers hunt a single disclosure: an unrestricted /proc/kallsyms, dmesg pointers, an uninitialized-memory read, or a timing side channel. Defenses respond by restricting leaks (kptr_restrict=2, dmesg_restrict=1) and, in hardened builds, FG-KASLR, which randomizes function order within the image so one leak no longer implies all offsets.

KPTI: separate page tables for user and kernel

KPTI (Kernel Page-Table Isolation) was introduced to mitigate Meltdown, a speculative-execution side channel that let userspace read kernel memory. With KPTI, a process running in user mode uses a page table in which the kernel is almost entirely unmapped; a small trampoline switches to the full kernel page table on entry.

For exploitation, KPTI removes some of the address-space-sharing that older techniques leaned on and requires exploits to route returns through the kernel's trampoline correctly. It is not an anti-ROP measure, but it is a pillar of the modern kernel's isolation model.

The defensive checklist

Kernel hardening is mostly configuration. Each option removes a capability an exploit needs:

Config / settingWhat it does
KASLR (default)Randomizes the kernel base; pair with leak restrictions
kptr_restrict=2, dmesg_restrict=1Hide kernel pointers from /proc and logs
CONFIG_STACKPROTECTOR_STRONGKernel stack canaries — detect stack overflows
SMEP / SMAP (default)Block ring-0 execution/access of userspace — see guide 2
KPTIUser/kernel page-table isolation (Meltdown + isolation)
CONFIG_SLAB_FREELIST_HARDENED / _RANDOMHarden and randomize the heap freelist against poisoning
CONFIG_RANDSTRUCTRandomize layout of sensitive structs (e.g. cred, file_operations)
CONFIG_CFI_CLANGKernel control-flow integrity on indirect calls
lockdown, seccomp, module signingShrink reachable attack surface

What this teaches a defender

  • Restrict leaks as aggressively as you randomize. KASLR is only as strong as the absence of a disclosure primitive. kptr_restrict and dmesg_restrict are cheap and high-value; FG-KASLR raises the cost further.
  • Layer, do not rely on one control. SMEP/SMAP force kernel ROP; KASLR forces a leak; canaries and freelist hardening block the corruption; CFI constrains the indirect calls. An exploit must beat all of them in sequence.
  • Attack surface is the cheapest win. Most kernel LPEs live in drivers and obscure syscalls. lockdown, seccomp filters, disabling unused modules and signing the ones you keep remove bugs from reach before any mitigation is tested.
  • Keep current. Kernel hardening (CR4 pinning, FG-KASLR, kernel CFI, freelist hardening) has improved steadily; an old kernel lacks defenses a new one has by default.

Key takeaways

  • KASLR randomizes the kernel base, but one leaked pointer derandomizes the whole single-image kernel — so restricting leaks matters as much as randomizing.
  • KPTI isolates user and kernel page tables (Meltdown mitigation and isolation), not a general anti-ROP control.
  • A hardened kernel stacks KASLR + leak restrictions + canaries + SMEP/SMAP + KPTI + freelist/struct hardening + CFI.
  • Reducing attack surface (lockdown, seccomp, fewer modules) is the highest-leverage measure of all.

This completes the Kernel Exploitation arc: from a bug to root, ret2usr and SMEP/SMAP, and the KASLR/KPTI defenses. Compare with the userland mitigation ordering in the mitigation stack.

Related guides

0x2000 · Exploit Mitigations

The Mitigation Stack: Which Defenses, In Order

Every exploit walks the same stages: bug, corruption, hijack, code execution, escalation. A defender's checklist of which mitigation stops each — across Linux, ARM, Windows and the kernel.

0xa000 · Windows Exploitation

Windows Flow-Integrity Mitigations: CFG and CET

How SafeSEH, SEHOP, ASLR, Control Flow Guard and hardware CET each close a Windows exploitation technique — what they check, how to enable them, and their limits.

0x8000 · ARM64 Exploitation

PAC and BTI: ARM's Answer to Code Reuse

Pointer authentication signs return addresses so a forged one faults; BTI forces indirect branches onto landing pads. How both work, how to enable and verify them, and their limits.