Kernel Security: KASLR, SMEP/SMAP, Spectre/Meltdown

Modern CPUs enforce privilege through hardware rings. x86 uses rings 0-3; Linux uses ring 0 (kernel) and ring 3 (user). The CPU enforces that ring-3 code cannot directly access ring-0 memory or execute privileged instructions like wrmsr, cli, or hlt. This boundary is the cornerstone of OS security.

When a user process needs a kernel service it issues a syscall instruction, which atomically switches to ring 0, saves the user-mode registers, and jumps to a kernel entry point. The reverse path (sysret or iretq) restores user context and drops privilege. Every single system call is a carefully guarded gate.

So why is the kernel still routinely exploited? Because:

1. The kernel is large and complex (~30 million lines of C). Bugs happen.
2. Any ring-0 code execution by an attacker immediately grants full machine control — there is no sandbox inside ring 0. An attacker who gets arbitrary kernel code execution can read every process's memory, install a rootkit, disable audit logging, or escape a container.
3. Many exploitation primitives are surprisingly simple: a linear buffer overflow that overwrites a function pointer, or a type confusion that lets you manufacture a fake kernel object with attacker-controlled fields.

The threat model for kernel security is therefore: a local unprivileged user (or a sandboxed process, or code in a VM guest) trying to escalate to root / ring 0 / host kernel. Every mitigation in this module is aimed at blocking one or more steps in that escalation chain.

/* How the kernel transitions from user to kernel mode on x86-64.
 * The CPU executes SYSCALL; the hardware does this conceptually: */
MSR_LSTAR  /* kernel's syscall entry address, set at boot */
           /* CPU saves RIP, CS, RFLAGS, RSP, SS into per-CPU regs */
           /* loads kernel CS and kernel stack from MSR_STAR / TSS */
           /* jumps to kernel entry_SYSCALL_64 in arch/x86/entry/entry_64.S */

/* To see the real entry path: */
/* arch/x86/entry/entry_64.S: entry_SYSCALL_64 */

The first thing an attacker needs when exploiting a kernel vulnerability is an address — the address of a kernel function to overwrite into a function pointer, the address of a gadget for a ROP chain, the address of the commit_creds function to elevate privileges. Before KASLR, these addresses were fixed at compile time and identical on every machine running the same kernel. Exploits simply hard-coded them.

KASLR, enabled by default since Linux 3.14 (2014), randomizes the base address at which the kernel image is loaded each time the system boots. The kernel is compiled as a Position-Independent Executable (PIE) (or with relocation tables). At boot, the bootloader or the kernel's decompressor picks a random offset (on x86-64, the offset is within a 1 GiB window, giving ~8-10 bits of entropy at 2 MB granularity; with CONFIG_RANDOMIZE_BASE and large-KASLR support, this grows).

What KASLR defeats: exploits that require knowing a precise kernel address up front. If you hard-code 0xffffffff81234567 into your exploit, it simply crashes the kernel instead of redirecting execution.

What KASLR does NOT defeat:

• Information leaks — any kernel memory disclosure that reveals a kernel pointer defeats KASLR instantly. /proc/kallsyms (restricted since Linux 4.15 to root by default), dmesg, and dozens of kernel interfaces historically leaked addresses. An attacker reads one address, computes the slide, and proceeds.
• Side-channel leaks (Spectre, timing attacks) can sometimes recover the KASLR slide.
• Brute force — on systems that don't enforce reboots or slow down on crashes (some embedded systems), low entropy KASLR can be brute-forced.

KASLR in practice: cat /proc/sys/kernel/kptr_restrict (value 1 or 2) controls whether unprivileged users see kernel pointers. Value 2 hides pointers even from root. dmesg_restrict similarly protects dmesg. These are the guards that make KASLR useful; without them it provides weak protection.

# Check KASLR status and address visibility
$ grep CONFIG_RANDOMIZE_BASE /boot/config-$(uname -r)
CONFIG_RANDOMIZE_BASE=y

# On x86-64: kernel base address after KASLR
$ sudo grep ' _text$' /proc/kallsyms
ffffffff91000000 T _text     # example: slid by 0x10000000

# Without root (kptr_restrict=1 or 2): addresses show as 0
$ grep ' _text$' /proc/kallsyms
0000000000000000 T _text

# Boot-time KASLR can be disabled for debugging:
# In grub: add 'nokaslr' to kernel command line

Even with KASLR, a classic kernel exploit technique called ret2usr worked beautifully: place shellcode in user space, then redirect a kernel function pointer to it. The CPU, executing in ring 0, would faithfully execute the attacker's user-space shellcode with kernel privileges. KASLR doesn't help here because the attacker controls the user-space address.

SMEP (Supervisor Mode Execution Prevention), introduced by Intel in Ivy Bridge (2012) and ARM as PXN (Privileged Execute Never), adds a single control: ring-0 code may not execute pages marked as user-accessible. The CPU checks the page table U/S bit at instruction fetch time. If a ring-0 instruction fetch hits a user-mode page, the CPU raises a page fault. Shellcode in user space simply cannot run from ring 0 anymore. This kills ret2usr.

SMAP (Supervisor Mode Access Prevention), introduced slightly later, extends this: ring-0 code may not even READ or WRITE user-space memory, unless the AC (Access Check) flag in RFLAGS is explicitly set via stac/clac instructions. The kernel legitimately needs to copy data from user space (e.g., copy_from_user()), so it temporarily sets AC, does the copy, then clears it immediately. This prevents an attacker from exploiting bugs where the kernel dereferences a user-controlled pointer without proper validation — the dereference itself faults.

SMEP/SMAP in the Linux kernel: enabled via bits 20 and 21 of CR4, set in arch/x86/kernel/cpu/common.c during early boot. You can verify: cat /proc/cpuinfo | grep smep and cat /proc/cpuinfo | grep smap.

Bypasses exist but are harder:

• Stack pivoting / kernel ROP: if the attacker can get the kernel to execute a ROP chain entirely within kernel text (which KASLR makes harder to find but not impossible), SMEP is irrelevant — no user-space execution needed.
• SMAP bypass: any code path that calls stac can be abused if an attacker can control execution at that point, briefly opening the window.
• Signal handler tricks (historical): some exploits mapped shellcode into a region that appeared as kernel memory due to a kernel mapping bug.

The key insight: SMEP/SMAP are hardware mitigations that require no software change in the hot path (the bit is set once at boot). They provide strong guarantees with near-zero performance cost.

/* How copy_from_user uses SMAP correctly (simplified) */
/* arch/x86/lib/copy_user_64.S */

/*
 * Before accessing user memory: set AC flag with STAC
 * After copy: clear AC flag with CLAC
 * The window where SMAP is disabled is as small as possible.
 */

/* In C, the kernel wrapper (include/linux/uaccess.h): */
static __always_inline unsigned long
__copy_from_user(void *to, const void __user *from, unsigned long n)
{
    /* __uaccess_begin() issues STAC (sets AC flag) */
    /* __uaccess_end()   issues CLAC (clears AC flag) */
    /* Any fault inside this window is handled by exception tables */
    instrument_copy_from_user_before(to, from, n);
    check_object_size(to, n, false);
    return raw_copy_from_user(to, from, n);
}

/* Verification: */
/* $ cat /proc/cpuinfo | grep -E 'smep|smap' */

This mitigation deserves its own section because it addresses a fundamentally different threat: a bug not in kernel code, but in CPU microarchitecture. But let us understand the design first, then the threat (Meltdown) in the next concept.

The pre-KPTI world: When a user process ran, the full kernel address space was mapped in the process's page tables — but marked not-accessible (supervisor-only). This was done for performance: every syscall would not need to switch page tables (an expensive operation involving a TLB flush). The kernel was 'present' in every process's virtual address space, just inaccessible.

KPTI (Kernel Page-Table Isolation), merged in Linux 4.15 (January 2018), splits page tables into two sets per process:

1. User-mode page tables: contains user-space mappings + only the minimal kernel stubs needed for syscall entry/exit (entry trampoline). The kernel proper is not mapped.
2. Kernel-mode page tables: the full kernel + user mappings (needed to copy data from user space).

On every kernel entry (syscall, interrupt, exception), the CPU switches CR3 (page table register) from the user PGD to the kernel PGD. On every kernel exit back to user space, CR3 switches back. This CR3 swap is the performance cost.

Performance impact: 5-30% for syscall-heavy workloads (database servers, Redis, etc.) because every syscall now incurs a TLB flush or PCID-keyed invalidation. Intel's PCID (Process-Context IDentifiers) feature allows keeping both sets of TLB entries tagged, reducing but not eliminating the cost. Modern kernels use PCID aggressively to soften this blow.

What KPTI defeats: Meltdown (explained next). Even if the CPU transiently reads kernel memory via speculative execution, the kernel is not mapped in user-mode page tables at all, so there is nothing to transiently read.

A secondary benefit: KPTI also makes KASLR stronger. An attacker using timing side channels to probe kernel addresses will find nothing mapped at all in user mode, making brute-force address probing much harder.

/* How to observe the CR3 switch cost via syscall latency:
 * On a KPTI-enabled system without PCID optimization:
 */

// A minimal benchmark: time a null syscall (getpid)
#include <sys/syscall.h>
#include <time.h>
#include <stdio.h>
int main() {
    struct timespec t0, t1;
    clock_gettime(CLOCK_MONOTONIC, &t0);
    for (int i = 0; i < 1000000; i++)
        syscall(SYS_getpid);
    clock_gettime(CLOCK_MONOTONIC, &t1);
    long ns = (t1.tv_sec - t0.tv_sec)*1e9 + (t1.tv_nsec - t0.tv_nsec);
    printf("%.1f ns/syscall\n", (double)ns / 1e6);
}
// On an Intel Skylake with KPTI + PCID: ~80-100 ns/syscall
// Without KPTI: ~40-60 ns/syscall
// The difference IS the page table switch cost.

// Check if KPTI is active:
// $ dmesg | grep -i 'kpti\|pti'
// Kernel/User page tables isolation: enabled

These two attacks, publicly disclosed on January 3, 2018 (though discovered independently by Google Project Zero, Cyberus Technology, and TU Graz months earlier), fundamentally changed our understanding of CPU security. They exploited not a software bug, but a design property of modern CPUs that had existed for 20 years.

Background — Out-of-Order and Speculative Execution: Modern CPUs do not execute instructions one-by-one. They look ahead, reorder instructions, execute multiple at once (out-of-order), and speculatively execute down predicted branch paths before knowing if the branch will be taken. If the prediction is wrong, the CPU retires (discards) the results of speculative work — it looks like nothing happened. Architecturally, nothing did happen: registers, memory, flags are all rolled back. This is the core of CPU performance since the Pentium Pro (1995).

The insight that broke everything: When speculative execution runs instructions that should not have run (e.g., instructions after a mispredicted branch, or instructions that access memory the program has no permission to read), those instructions:

1. Are architecturally rolled back — the program sees no result.
2. But leave microarchitectural traces — cache lines are loaded into the L1/L2/L3 caches. These cache loads are NOT rolled back.

An attacker can measure whether a cache line is hot or cold by timing a memory access (Flush+Reload, Prime+Probe). This is a side channel: information leaks through a covert channel (cache timing) even though no architectural state changed.

Meltdown (CVE-2017-5754): A user-space process tries to load from a kernel address. This is a privilege violation — the CPU will raise a page fault. But before the page fault is delivered, the CPU speculatively continues executing, loading the kernel data into a register and using it to index into an array ('probe array'). That array access loads a cache line corresponding to the secret byte value. Then the page fault fires and architectural state is rolled back. But the cache is warm. The attacker does a timing probe of 256 entries in the probe array and sees which one is fast — revealing the secret kernel byte. This works because Intel CPUs (and some ARM cores) performed the access-permission check too late in the pipeline.

Spectre (CVE-2017-5753, CVE-2017-5715): Subtler and much harder to fully mitigate. Instead of crossing privilege boundaries, Spectre trains the CPU branch predictor to speculatively execute a 'gadget' inside the victim's own address space — including the kernel itself. There are multiple variants:

• Variant 1 (bounds-check bypass): An attacker trains the branch predictor that an array-bounds check will pass. The CPU speculatively executes beyond the bounds, loading a secret value and performing a dependent cache load. The speculative execution is rolled back, but the cache is hot.
• Variant 2 (branch target injection): The attacker poisons the indirect branch predictor (BTB) so that an indirect call in the kernel will speculatively jump to an attacker-chosen gadget, which leaks data via a cache side channel.

Why Spectre is so hard to fix: Meltdown was a hardware bug in Intel's implementation (AMD was not affected). KPTI fixed it by ensuring kernel memory is not mapped at all in user mode — nothing to speculatively read. But Spectre is inherent to the design of speculative execution itself. The CPU must speculate to be fast; speculation with shared microarchitectural state (caches, branch predictors) leaks information. Full fixes require architectural redesigns that are appearing slowly in newer chips.

/* Meltdown: conceptual pseudocode of the attack kernel read.
 * Do NOT run this on a production system.
 * This is pedagogical pseudocode — a real exploit needs
 * careful cache flush/timing, retry logic, etc. */

#include <stdint.h>
#include <string.h>
#include <x86intrin.h>   /* for __rdtsc, _mm_clflush */

#define CACHE_HIT_THRESHOLD 80
#define PAGE_SIZE 4096

uint8_t probe_array[256 * PAGE_SIZE]; /* 256 pages, one per possible byte value */

/* Step 1: flush the entire probe array from cache */
void flush_probe_array(void) {
    for (int i = 0; i < 256; i++)
        _mm_clflush(&probe_array[i * PAGE_SIZE]);
}

/* Step 2: the speculative read gadget.
 * This will fault when trying to read *kernel_addr,
 * but BEFORE the fault, the CPU speculatively does:
 *   secret = *kernel_addr        (privileged read!)
 *   _ = probe_array[secret * PAGE_SIZE]  (cache load)
 */
void __attribute__((noinline)) meltdown_read(uint8_t *kernel_addr) {
    /* Attempt the forbidden read. Will fault. */
    uint8_t secret = *kernel_addr;
    /* Speculative: access probe array indexed by secret */
    (void)probe_array[secret * PAGE_SIZE];
    /* CPU retires fault, rolls back secret. Cache line stays hot. */
}

/* Step 3: time all 256 probe_array entries */
int measure(void) {
    int winner = -1;
    uint64_t min_time = ~0ULL;
    for (int i = 0; i < 256; i++) {
        uint64_t t0 = __rdtsc();
        (void)probe_array[i * PAGE_SIZE];
        uint64_t t1 = __rdtsc();
        if ((t1 - t0) < CACHE_HIT_THRESHOLD && (t1-t0) < min_time) {
            min_time = t1 - t0;
            winner = i; /* This byte was in cache -> secret! */
        }
    }
    return winner;
}

Because Spectre is an architectural problem, the mitigations are a patchwork of partial fixes, each trading some performance for some security. Understanding them requires understanding what they each target.

Retpoline ('return trampoline'), invented by Google's Paul Turner and merged in Linux 4.15, targets Variant 2 (Branch Target Injection). The idea: replace every indirect call/jump in the kernel with a construct that speculates to an infinite loop instead of an attacker-controlled target.

A normal indirect call jmp [rax] lets the CPU speculate to whatever the Branch Target Buffer (BTB) predicts — which an attacker can poison. A retpoline replaces this with:

  call set_up_return;
capture_spec:
  pause; lfence; jmp capture_spec;  /* infinite loop; CPU speculates here */
set_up_return:
  mov [rsp], rax;  /* overwrite return address with actual target */
  ret;             /* CPU speculates to the pause loop, but actualy returns to rax */

The CPU speculates down the pause; jmp loop (harmless, leaks nothing), while the actual execution returns to the correct indirect target. This is clever misdirection using the CPU's own return address stack (RSB) which is not attacker-pollutable in the same way.

IBRS (Indirect Branch Restricted Speculation): A new MSR introduced by Intel microcode updates. When set, prevents indirect branches from being influenced by predictions trained in a different privilege level. Strong but has high performance cost on older microarchitectures. Enhanced IBRS (eIBRS) on newer Intel chips (Ice Lake+) provides similar protection with much lower overhead.

STIBP (Single Thread Indirect Branch Predictors): Prevents a hyperthread on one SMT sibling from poisoning the indirect branch predictor of the other. Required for cross-SMT Spectre attacks. Has performance cost; some systems disable SMT entirely as a nuclear option.

LFENCE as a speculation barrier: For Variant 1 (bounds check bypass), the compiler can insert lfence instructions after array bounds checks to prevent the speculative window. The kernel uses array_index_nospec() macro for this. The downside: every bounds-checked array access in performance-critical kernel code gets a barrier.

SSBD (Speculative Store Bypass Disable): Targets Spectre Variant 4, where a store and a subsequent load to the same address can be bypassed speculatively. Controlled via prctl(PR_SET_SPECULATION_CTRL, ...).

Checking mitigations on your system:

$ cat /sys/devices/system/cpu/vulnerabilities/*

This gives you the status of every known speculative execution vulnerability on your CPU.

/* Retpoline: the actual GCC-generated sequence for an indirect call.
 * Compiler flag: -mindirect-branch=thunk-extern
 * The kernel builds with this flag when CONFIG_RETPOLINE=y
 */

/* Before retpoline: indirect call via register */
/*   call *%rax   */
/* After retpoline (using __x86_indirect_thunk_rax): */

/* __x86_indirect_thunk_rax: */
/*     call set_up_thunk       */
/* spec_trap:                  */
/*     pause                   */  /* hint: spin-wait, low power */
/*     lfence                  */  /* speculation barrier */
/*     jmp  spec_trap          */  /* infinite speculation sink */
/* set_up_thunk:               */
/*     mov  %rax, (%rsp)       */  /* plant real target as return addr */
/*     ret                     */  /* RSB predicts spec_trap; actual: rax */

/* Check retpoline status: */
/* $ grep . /sys/devices/system/cpu/vulnerabilities/spectre_v2 */
/* Mitigation: Retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional ... */

/* Use array_index_nospec for variant 1 defense in kernel code: */
#include <linux/nospec.h>
static int read_kernel_array(int idx) {
    idx = array_index_nospec(idx, ARRAY_SIZE(my_array)); /* inserts LFENCE */
    return my_array[idx];
}

The stack buffer overflow is perhaps the most classic of all exploit classes, described in Aleph One's legendary 1996 paper 'Smashing the Stack for Fun and Profit'. The idea: a function stores a local buffer on the stack, followed by the saved return address. If the buffer can be overflowed (e.g., by a strcpy with no bounds check), the attacker overwrites the return address with a pointer to shellcode. When the function returns, execution jumps to the shellcode.

Stack canaries (named after canaries in coal mines) defend against this. GCC's Stack Smashing Protector (-fstack-protector-strong, used by the kernel since around 3.14) inserts a random secret value (the 'canary') between the local variables and the saved return address on every stack frame. Before ret, the compiler inserts code to check whether the canary has been modified. If it has, the program calls __stack_chk_fail(), which in the kernel panics immediately rather than executing the corrupted return address.

How the canary works in the kernel: The kernel uses a per-CPU or per-task random value stored in a memory location not accessible from user space (backed by the stack canary infrastructure in arch/x86/include/asm/stackprotector.h). The canary is initialized from /dev/random at boot and refreshed periodically.

Limitations:

• Does not protect against overwrites that skip the canary (e.g., a heap overflow that targets a function pointer in a heap object, not the stack).
• Does not protect against read-only exploitation — an attacker who can read the canary (via an information leak) can then reproduce it in the overflow, bypassing the check.
• Does not protect against integer overflows that lead to heap corruption rather than stack corruption.
• Only covers return addresses by default; function pointers in stack-allocated structs may still be overwriteable without touching the canary.

Despite limitations, SSP is cheap (one store and one compare per function) and catches a large class of real bugs, making it a valuable first-line defense.

/* What GCC -fstack-protector-strong generates conceptually */

/* Original vulnerable function: */
void vulnerable(char *input) {
    char buf[64];
    strcpy(buf, input); /* dangerous! no bounds check */
}

/* With SSP, the compiler transforms it to roughly: */
void vulnerable_protected(char *input) {
    /* canary placed BETWEEN buf and saved RIP */
    unsigned long __canary = __stack_chk_guard; /* per-task random value */
    char buf[64];
    strcpy(buf, input); /* still dangerous but... */
    /* Before return: */
    if (__canary != __stack_chk_guard)
        __stack_chk_fail(); /* kernel BUG() / panic */
}

/* Check: look at the actual assembly with -fstack-protector-strong */
/* cc -O2 -fstack-protector-strong -S -o - example.c | grep -A5 'canary' */

/* In kernel config: */
/* CONFIG_STACKPROTECTOR=y */
/* CONFIG_STACKPROTECTOR_STRONG=y */

Modern kernel exploits rarely work by overflowing a buffer and overwriting a return address. SMEP, SMAP, canaries, and ASLR have collectively raised the bar so high that attackers now use Return-Oriented Programming (ROP) and Call-Oriented Programming (COP): instead of injecting new code, they chain together existing 'gadgets' — short sequences of legitimate kernel code ending in ret or jmp [reg]. By overwriting a single pointer (function pointer, return address, vtable entry) they steer execution through a chain of gadgets that together perform the desired attack.

Control-Flow Integrity (CFI) is the class of mitigations designed to defeat this. The core idea: restrict which targets are valid for any given indirect call or return. A CFI scheme adds runtime checks that enforce a control-flow graph derived from static analysis: this indirect function pointer may only be called with functions of the correct type signature, not arbitrary gadget addresses.

Clang CFI (used by Android's kernel, available for mainline Linux with CONFIG_CFI_CLANG since ~5.13): uses Clang's LTO (Link-Time Optimization) to compute, at compile time, the set of valid targets for every indirect call. Inserts an inline check before each indirect call that verifies the target is in the valid set. Uses a hash of the function's type signature for the check.

Shadow Call Stack (SCS) (ARM64 in Linux 5.10, x86 planned): maintains a separate, hidden stack (in a register-addressable but not stack-pointer-reachable location) that stores only return addresses. On CALL, the return address is saved to both the normal stack AND the shadow stack. On RET, the return address is compared against the shadow stack. If they differ, execution is aborted. This specifically targets ROP chains that rely on overwriting return addresses.

Hardware CFI: Intel CET (Control-flow Enforcement Technology), available since Tiger Lake (2020), provides hardware-level shadow call stack (SHSTK) and indirect branch tracking (IBT). Linux gained CET/IBT support in 6.2. These have near-zero performance overhead compared to software CFI.

Current state in mainline Linux: CFI is opt-in and architecture/compiler specific. Android adopted Clang CFI broadly. Mainline Linux has CONFIG_CFI_CLANG, CONFIG_SHADOW_CALL_STACK (arm64), and Intel IBT support. This is an active area of development.

/* CFI type-hash check (what Clang CFI inserts before indirect calls) */
/* Conceptual equivalent of what the compiler generates: */

typedef void (*fn_t)(int);

void call_with_cfi(fn_t fn_ptr, int arg) {
    /* Clang CFI inserts something like this before the actual call: */
    /* __cfi_check(fn_ptr, expected_type_hash); */
    /* If fn_ptr does not point to a function with matching type,
     * the check fails and __cfi_slowpath() is called -> kernel BUG() */
    fn_ptr(arg); /* actual call, only reachable if check passed */
}

/* Shadow Call Stack on ARM64 (x18 register is the shadow SP): */
/* Function prologue (compiler-inserted): */
/*   str x30, [x18], #8    // save LR to shadow stack, advance shadow SP */
/* Function epilogue: */
/*   ldr x30, [x18, #-8]!  // load LR from shadow stack */
/*   ret                   // use shadow-stack LR, not stack LR */

/* If an attacker overwrites the return address on the normal stack,
 * the shadow stack still holds the legitimate value,
 * and the comparison/load from x18 will detect the mismatch. */

/* Check if CFI is enabled: */
/* $ grep 'CONFIG_CFI_CLANG\|CONFIG_SHADOW_CALL_STACK' /boot/config-$(uname -r) */

To understand why mitigations are designed the way they are, you need to understand the underlying exploit primitives they are defending against. Here are the canonical exploit classes every kernel security engineer must know.

1. Stack Buffer Overflow: Overflow a stack-allocated buffer to overwrite the saved return address or a local function pointer. Defended by canaries and CFI. Example: classic gets() in a syscall handler.

2. Heap Buffer Overflow / Heap Corruption: Overflow a slab-allocated kernel object to corrupt adjacent objects. The SLUB allocator attempts to detect some corruption (CONFIG_SLUB_DEBUG), but exploitation is highly primitive-dependent. Common target: overwriting a function pointer in an adjacent kernel object (e.g., struct file_operations).

3. Use-After-Free (UAF): After freeing a kernel object, a reference to it remains (dangling pointer). The attacker allocates a new object of the right size in the freed slot (by triggering slab allocation), filling it with attacker-controlled data. The original dangling pointer now reads/writes attacker data, often leading to type confusion or arbitrary read/write. UAF is the dominant class of modern kernel exploits (look at CVE statistics 2020-2024).

4. Type Confusion: The kernel uses the wrong type to interpret a memory region. If an attacker can allocate objects such that a type-A pointer points to a type-B object they control, they can manufacture fake kernel structures with arbitrary field values.

5. Null Pointer Dereference: Before mmap_min_addr was enforced (Linux 2.6.23+), attackers could map page 0 in user space and cause a kernel null dereference to land in attacker-controlled code. sysctl vm.mmap_min_addr now defaults to 65536 on most systems, preventing page 0 mapping.

6. Race Conditions (TOCTOU, UAF races): The kernel is heavily concurrent. A 'Time of Check to Time of Use' bug lets an attacker modify data between the kernel's permission check and its use. Famous example: Dirty COW (CVE-2016-5195) — a race in mmap copy-on-write allowed writing to read-only file mappings.

7. Integer Overflow: An integer computation wraps, causing an allocation to be too small or an index to go out of bounds. Classic: size_t alloc = n * sizeof(struct foo) overflows when n is large, allocating a tiny buffer that is then overflowed.

The exploitation pipeline: In practice, a kernel exploit chains multiple primitives: an initial memory corruption bug gives a constrained write (the 'vulnerability'), which is upgraded to an arbitrary read/write primitive (the 'exploitation technique'), which is then used to overwrite cred->uid to 0 or call commit_creds(prepare_kernel_cred(NULL)) (the 'payload').

/* Simplified Use-After-Free scenario in kernel C */

struct my_obj {
    int data;
    void (*callback)(struct my_obj *);
};

struct my_obj *obj;

void path_A(void) {
    kfree(obj);     /* Object freed. obj pointer NOT cleared. */
    /* Bug: obj is now a dangling pointer */
}

void path_B(void) {
    /* Attacker triggers this after path_A:
     * Allocates a same-sized slab object with attacker-controlled content.
     * obj now points to attacker-controlled memory.
     */
    obj->callback(obj); /* Calls arbitrary function pointer! -> RIP control */
}

/* Mitigation approaches:
 * 1. Set obj = NULL after kfree (coding discipline)
 * 2. CONFIG_INIT_ON_FREE_DEFAULT_ON: zero freed memory (makes UAF harder)
 * 3. Heap quarantine / freelist randomization (CONFIG_SLAB_FREELIST_RANDOM)
 * 4. Struct randomization (CONFIG_RANDSTRUCT): randomizes field offsets
 *    making it harder to predict the offset of 'callback'
 */

Beyond the big mitigations above, the kernel ships dozens of smaller hardening features. Understanding them rounds out the picture.

Kernel Lockdown (CONFIG_SECURITY_LOCKDOWN_LSM, merged 5.4): A Linux Security Module that restricts what even root can do when Secure Boot is active. In 'integrity' mode, root cannot load unsigned kernel modules, cannot access raw /dev/mem, cannot modify the running kernel via kexec unsigned kernels. In 'confidentiality' mode, root cannot even read kernel memory via /dev/mem or hibernation images. This prevents a compromised root process from persistently modifying the kernel.

seccomp (Secure Computing mode): Allows a process to restrict itself to a whitelist of syscalls using BPF filters. If a sandboxed process (a browser tab, a container process) is exploited, the attacker faces a minimal syscall surface. Chrome/Firefox/Docker all use seccomp. Syscalls like ptrace and process_vm_readv that are dangerous for lateral movement are often blocked.

Hardened usercopy (CONFIG_HARDENED_USERCOPY): Validates that copy_from_user/copy_to_user calls do not exceed the size of the kernel object being copied to/from. Detects a class of bugs where kernel copy routines are used to read/write beyond object boundaries — a surprisingly common source of information leaks.

RANDSTRUCT (CONFIG_RANDSTRUCT): Randomizes the layout of sensitive kernel structs (like struct cred, struct task_struct) at compile time. An attacker who has a memory corruption primitive and wants to overwrite cred->uid needs to know the exact offset of uid inside cred. Randomization makes that offset vary per kernel build.

FORTIFY_SOURCE: Like glibc's _FORTIFY_SOURCE, this enables compile-time and runtime checks on common buffer operations (memcpy, strcpy, etc.) using known object sizes. If the compiler knows the destination buffer is 64 bytes and a memcpy would copy 128 bytes, it aborts.

Namespace isolation + user namespaces: Relevant to container security. User namespaces allow unprivileged container processes to appear as root inside their namespace. This has been a significant source of privilege escalation bugs because code paths gated on 'is this process root?' can be reached by unprivileged users inside a user namespace. sysctl kernel.unprivileged_userns_clone (on some distributions) disables this surface.

/* seccomp-BPF: restrict a process to read/write/exit only */
#include <seccomp.h>  /* libseccomp */
#include <stdio.h>

int main(void) {
    scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL); /* default: kill */
    /* Allow only these syscalls: */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read),   0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write),  0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit),   0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);
    seccomp_load(ctx);
    seccomp_release(ctx);
    /* From this point: any syscall not in the list kills the process */
    write(1, "sandboxed\n", 10);
    /* open("/etc/passwd", O_RDONLY) would be KILLED */
    return 0;
}
/* Compile: gcc -o sandbox sandbox.c -lseccomp */
/* This is exactly what Chrome's renderer processes do. */

The Linux kernel provides several interfaces that let you inspect the security posture of a running system. Every kernel security engineer should know these by heart.

/sys/devices/system/cpu/vulnerabilities/: Every known CPU speculative execution vulnerability has a file here. The contents describe the current mitigation status. Values like Mitigation: Retpoline, Vulnerable, Not affected, or Mitigation: PTI tell you exactly what protection is active.

/proc/sys/kernel/: Contains security-relevant sysctls:

• kptr_restrict (0/1/2): controls kernel pointer exposure in /proc files
• dmesg_restrict (0/1): controls dmesg access by unprivileged users
• perf_event_paranoid (-1/0/1/2/3): controls perf event access; setting 3 disables perf for unprivileged users, removing a significant Spectre-relevant side channel
• unprivileged_bpf_disabled (0/1/2): BPF is a major Spectre attack surface; restricting it is important on multi-tenant systems
• randomize_va_space (0/1/2): ASLR for user processes; 2 is full randomization

/proc/self/status: Contains Speculation_Store_Bypass and SpeculationIndirectBranch lines showing per-process Spectre mitigation modes.

checksec: A popular shell script / tool that inspects an ELF binary for security properties (NX, PIE, RELRO, canary, RPATH). There is also a kernel-targeted variant. Useful for understanding a kernel module's security posture.

kconfig: The real source of truth. grep through /boot/config-$(uname -r) for CONFIG_RANDOMIZE_BASE, CONFIG_STACKPROTECTOR_STRONG, CONFIG_CFI_CLANG, CONFIG_SHADOW_CALL_STACK, CONFIG_HARDENED_USERCOPY, etc. The presence or absence of these options tells the whole security story of a given kernel build.

#!/bin/bash
# Quick kernel security posture audit

echo '=== CPU Vulnerability Status ==='
for f in /sys/devices/system/cpu/vulnerabilities/*; do
    printf '%-30s %s\n' "$(basename $f):" "$(cat $f)"
done

echo
echo '=== Key Security Sysctls ==='
for sysctl in \
    kernel.kptr_restrict \
    kernel.dmesg_restrict \
    kernel.perf_event_paranoid \
    kernel.unprivileged_bpf_disabled \
    kernel.randomize_va_space \
    vm.mmap_min_addr; do
    printf '%-40s %s\n' "$sysctl" "$(sysctl -n $sysctl 2>/dev/null || echo N/A)"
done

echo
echo '=== Kernel Config Hardening ==='
for opt in \
    CONFIG_RANDOMIZE_BASE \
    CONFIG_STACKPROTECTOR_STRONG \
    CONFIG_HARDENED_USERCOPY \
    CONFIG_RANDSTRUCT \
    CONFIG_CFI_CLANG \
    CONFIG_SHADOW_CALL_STACK \
    CONFIG_SECURITY_LOCKDOWN_LSM; do
    val=$(grep "^$opt" /boot/config-$(uname -r) 2>/dev/null || echo 'NOT SET')
    printf '%-45s %s\n' "$opt" "$val"
done