Linux local privilege escalation: an archive overview

Updated Nov 2026•Kernel and exploits

This page replaces an old directory that once held public source files for local root exploits against Linux kernels in the 2.6 and 3.x series. None of those files are hosted here. What follows is a short history of the bug classes involved and the defences that made them far harder to use.

The shape of the problem

A local privilege escalation turns an unprivileged account into root on the same machine. In that era, most public examples abused kernel code that was reachable from ordinary system calls and that mishandled a pointer, a length or a missing check. Typical classes were NULL-pointer dereferences, missing validation of user-supplied addresses, integer and size errors, and use of uninitialised or stale data. Two well-known examples are CVE-2009-2692, a flaw in how the socket sendpage path handled a missing function pointer, and CVE-2008-0600, a flaw in the vmsplice system call.

Why the NULL page mattered

On the common x86 layouts, kernel code ran in the same address space as the process that called it. If the kernel followed a pointer that happened to be null, the processor looked at address zero, and a local user could have mapped their own memory there. Whatever the kernel then read, such as a table of function pointers, was under the attacker's control, and execution moved to code of their choosing. The kernel was effectively tricked into running user-supplied instructions with full privileges.

The first defence was the mmap_min_addr setting, which forbids unprivileged programs from mapping the lowest part of the address space. This turned a large group of NULL dereferences from code execution into a mere crash. Early on it was often left unset, or was bypassed through other bugs and security modules, which is why those exploits stayed useful for some years.

The mitigations that ended the era

• SMEP and SMAP. Processor features that stop the kernel from executing, and then from accessing, user-space memory by accident. Redirecting kernel execution to a user-mapped page no longer works by default.
• KASLR. Randomising where the kernel is loaded removes the fixed addresses that old exploits hard-coded.
• Hardening ideas from grsecurity and PaX. Concepts such as non-executable kernel data, restricted dmesg and kernel pointer hiding, and removal of dangerous interfaces were developed there first, and many reached the mainline kernel in some form.
• Faster patching and distribution. Stable kernel releases, live patching and automatic updates shortened the window in which a published bug was usable in practice.

What to take from it

Attackers moved on to chaining information leaks with memory corruption, which is far more work than a single NULL dereference. For defenders, the practical advice is unchanged: keep kernels patched, enable the hardware and kernel mitigations, remove unneeded kernel modules and interfaces, and limit what unprivileged users can reach. Old bugs are still worth studying because the same mistakes keep reappearing in new code.