# Kernel Exploit Development
Kernel exploit development is the craft of identifying vulnerabilities within an operating system kernel and constructing functional attack code that transforms those vulnerabilities into reliable, repeatable system compromises. It exists because the kernel is the foundational layer of trust on any computing system: code executing at kernel privilege operates outside every user-space control, policy enforcement mechanism, and security boundary that defenders build. Attackers pursue kernel exploits because no sandbox, no mandatory access control framework, and no containerization technology can constrain code running at ring 0. For defenders, understanding how kernel exploits are developed is not optional knowledge. It is the prerequisite for making rational decisions about patch velocity, kernel hardening configuration, and the real boundaries of any defensive architecture.
---
Kernel exploit development is the technical discipline of taking a confirmed or suspected vulnerability in the kernel of an operating system and producing code that exercises that vulnerability to achieve a security objective, typically privilege escalation from an unprivileged or restricted user context to full kernel execution authority.
This discipline is distinct from adjacent concepts in several important ways. Kernel exploit development is not the same as kernel vulnerability research, which stops at confirming that a flaw exists and documenting its root cause. It is not the same as exploit framework usage, where an operator loads a pre-built module without understanding the underlying primitive. It is not the same as rootkit development, which focuses on persistence and stealth after privilege has already been obtained.
The variants within kernel exploit development map primarily to the vulnerability class being weaponized. Use-after-free exploits target memory that the kernel has freed but not yet reallocated, allowing an attacker to control what object occupies that memory next. Race condition exploits introduce carefully timed concurrency to create exploitable windows in system call handlers. Heap spray techniques manipulate the kernel allocator to position controlled data at predictable addresses. Type confusion bugs cause the kernel to treat one data structure as a different type, enabling controlled reads or writes. Integer overflow exploits corrupt size or offset calculations during memory operations, often leading to buffer overflows in kernel context.
Kernel exploit development also encompasses the techniques required to defeat modern mitigations: Kernel Address Space Layout Randomization (KASLR), Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), and Control Flow Integrity (CFI). A vulnerability alone is almost never sufficient. Modern kernel exploit development is fundamentally an exercise in chaining primitives: a leak primitive defeats KASLR, a write primitive modifies a kernel structure, and a control-flow primitive redirects execution.
---
The kernel exploit development process moves through several distinct stages, each building on the last. Understanding each stage is what separates practitioners who can assess real risk from those who rely on assumptions.
Stage 1: Vulnerability Identification
Discovery begins with one of three approaches: source code auditing, dynamic fuzzing, or CVE analysis. Source code auditing against open-source kernels such as the Linux kernel involves systematic review of subsystems that handle untrusted input: network drivers, file system implementations, and kernel interfaces exposed via system calls. Auditors look for memory lifecycle errors, missing bounds checks, and incorrect locking discipline.
Dynamic fuzzing with tools such as syzkaller generates structured, semantically valid system call sequences at high volume and monitors the kernel for crashes, hangs, or memory corruption signals. Syzkaller uses coverage-guided feedback to evolve inputs toward unexplored kernel code paths. Google's Project Zero and independent researchers have credited syzkaller with discovering hundreds of kernel vulnerabilities across Linux, Android, and other platforms.
CVE-driven development starts with a published advisory. The developer reads the description, identifies the affected code path, and attempts to construct a proof-of-concept before the patch is widely deployed. This approach is common in real-world offensive operations because the vulnerability is already confirmed and the researcher's effort focuses entirely on weaponization.
Stage 2: Primitive Construction
A primitive is a controlled, repeatable capability derived from a vulnerability. The three most important primitives in kernel exploit development are the read primitive, the write primitive, and the execute primitive.
A read primitive allows the attacker to read arbitrary kernel memory. This is frequently the first primitive constructed because it enables KASLR bypass. By reading a kernel pointer from a known structure, the developer can calculate the kernel's actual base address at runtime and correct all subsequent address calculations accordingly.
A write primitive allows the attacker to write controlled data to an arbitrary kernel address. This is used to corrupt kernel data structures. The most common target in Linux kernel exploits has historically been the cred structure attached to the current process. This structure holds the user ID, group ID, and capability sets associated with the running process. Writing zeros to the UID and GID fields of this structure effectively grants the process root identity. This technique has appeared in exploitation of CVE-2017-7308 (a socket ring buffer vulnerability), CVE-2021-3490 (an eBPF verifier integer overflow), and numerous others.
Stage 3: Mitigation Defeat
Modern kernels ship with layered mitigations that complicate each stage above. KASLR randomizes the kernel's load address at boot, invalidating hardcoded addresses. Exploit developers defeat KASLR by first constructing a read primitive and leaking a kernel pointer from user-accessible structures or timing side channels. SMEP prevents the kernel from executing code located in user-space pages. Developers defeat SMEP by ensuring their shellcode or return-oriented programming (ROP) chain resides entirely within kernel memory. SMAP prevents kernel code from directly reading user-space data without explicit annotation. CFI, increasingly available in Android kernels and some Linux configurations, restricts indirect call targets to statically validated sets.
Stage 4: Reliability Engineering
A proof-of-concept that crashes the kernel half the time is not a weapon. Reliability engineering involves controlling heap state before triggering the vulnerability, ensuring that allocations land at predictable offsets, handling NUMA topology effects, and managing timing windows in race condition exploits. Race condition exploits in particular require techniques such as CPU affinity pinning, high-priority thread scheduling, and loop amplification to widen the exploitable window to a reliably hittable size.
Concrete Scenario: eBPF Verifier Exploit
In 2021, CVE-2021-3490 demonstrated the maturity of this development process. The Linux eBPF verifier, responsible for statically validating programs before the kernel executes them, contained an integer overflow in its bounds tracking logic. An attacker could submit a specially crafted eBPF program that the verifier incorrectly approved. When the kernel's JIT compiler ran the program, it executed out-of-bounds memory reads and writes. Public exploit code for this vulnerability chained a KASLR leak, a controlled write to the cred structure, and privilege escalation to root in under two seconds on affected Ubuntu systems. The exploit worked reliably on systems that had not yet applied the patch, illustrating how quickly a vulnerability class transitions from theory to deployable capability.
---
Kernel exploits are categorically different from user-space exploits in their security impact. A compromised user-space process operates within the constraints placed on it by the kernel. A compromised kernel has no constraints. Every security control layered above the kernel, including SELinux, AppArmor, seccomp filters, container namespaces, and hypervisor guest isolation (in some configurations), becomes ineffective once the kernel itself is controlled.
This matters operationally for several specific reasons. First, detection is extraordinarily difficult. Endpoint detection tools, host-based intrusion detection systems, and security agents all run in user space. A kernel-level attacker can manipulate the data those tools read, hide processes, suppress audit log writes, and intercept system calls before they are recorded. From the perspective of any user-space observer, the system may appear entirely clean.
Second, the blast radius of a single kernel vulnerability extends across entire infrastructure fleets. Cloud providers run thousands of virtual machines on shared kernel versions. Enterprise environments standardize on specific kernel releases for compatibility reasons and update slowly. A single unpatched vulnerability in a widely deployed kernel version represents simultaneous exposure across every instance of that configuration.
Third, kernel exploits are frequently the final link in a multi-stage attack chain. An attacker who has achieved initial access through phishing or a web application vulnerability operates in a restricted context. A kernel exploit converts that foothold into full system ownership, enabling credential harvesting, lateral movement, and the installation of persistent implants that survive reboots.
A common misconception is that kernel exploits are exclusively the domain of nation-state actors. This was plausibly true before 2015. It is not true now. Public repositories contain functional kernel exploit code for hundreds of CVEs. Ransomware groups including those deploying Ryuk and its successors have incorporated privilege escalation techniques that depend on kernel vulnerability exploitation. The skill floor for deploying an existing exploit is far lower than the skill floor for developing one, and that gap has security consequences for every organization.
The real-world consequence of the Dirty Cow vulnerability (CVE-2016-5195), a race condition in the Linux kernel's copy-on-write mechanism, illustrates this point. Within weeks of public disclosure, proof-of-concept code was embedded in attack tools targeting Android devices, shared hosting environments, and container breakout scenarios. Systems that were weeks behind on patching were fully compromised by attackers who had never written a line of kernel exploit code themselves.
---
CDA approaches kernel exploit development as an analytical input to the Planetary Defense Model (PDM), specifically within the Vulnerability Surface Domain (VSD). The guiding principle of Continuous Surface Reduction (CSR) states: "Every surface you expose is a surface we eliminate." When applied to kernel exploit risk, this principle translates into a specific operational methodology rather than a set of recommendations.
CDA practitioners begin with kernel attack surface enumeration: which system calls are exposed to which processes, which kernel modules are loaded and unnecessary, which eBPF program types are permitted, and whether unprivileged user namespace creation is enabled. Each of these represents a potential attack entry point. CDA's VSD methodology assigns each surface a weighted risk score based on the availability of public exploit code, the patch status of the running kernel, and the presence or absence of specific mitigations such as SMEP, SMAP, and kernel pointer exposure restrictions (via /proc/sys/kernel/kptr_restrict).
What CDA does differently is connect kernel vulnerability status directly to compensating control decisions. When a critical kernel CVE is published and patch deployment will take days because of operational constraints, CDA's CSR workflow activates surface-specific controls: restricting the vulnerable code path through seccomp policy, disabling the affected kernel module if the workload permits, or isolating affected systems to reduced-trust network segments. These are not permanent mitigations. They are time-bounded risk reductions that hold the line while patching completes.
CDA also treats kernel exploit research as intelligence. The VSD team maintains a watch list of kernel CVEs with public proof-of-concept code, updated continuously. When a new entry appears, it triggers a cross-environment assessment: which systems run the affected kernel version, which of those systems have the vulnerability class's prerequisites in place (for example, unprivileged user namespaces enabled), and which have the relevant mitigations disabled for compatibility reasons. This workflow converts a generic advisory into a prioritized, environment-specific action list within hours rather than days.
Operationally, CDA's approach rejects the notion that kernel security is purely a patching problem. Patch cadence matters, but surface reduction before a vulnerability is even known is the more durable posture.
---
checksec for kernels and audit /proc/cpuinfo flags to verify.---
---