Linux Kernel Exploits

When escalation via misconfigurations (sudo, SUID, cron, capabilities) bears no fruit, what remains is exploiting a vulnerability in the Linux kernel itself. A successful kernel exploit gives root directly, regardless of permissions and configurations. But it’s the last resort: many exploits are unstable, can crash (kernel panic) the host, and are very noisy. First exhaust the configuration paths (see Linux Privilege Escalation).

Why it’s the last resort

• Crash risk: a badly ported exploit can cause a kernel panic and take down the server (in a real pentest, this is serious).
• Noise: kernel exploits tend to be EDR-detectable and leave traces.
• Variable reliability: they depend on the exact version, architecture, and mitigations (KASLR, SMEP/SMAP).

So: enumerate and try everything else first; the kernel only when there’s no other way.

Identify the version and map exploits

uname -a                       # exact kernel version and architecture
cat /etc/os-release            # distro (affects which patches are backported)
cat /proc/version
# tools that suggest exploits by version
linux-exploit-suggester.sh     # (LES) maps CVEs/exploits to the kernel
linux-exploit-suggester-2.pl
# cross-reference manually: searchsploit linux kernel <version>

Careful: the distro may have backported the patch without changing the major version number. LES helps, but verify.

Famous kernel CVEs (reference)

Dirty COW (CVE-2016-5195)      COW race condition -> write to read-only files
Dirty Pipe (CVE-2022-0847)     overwrite read-only files via pipes -> root
PwnKit (CVE-2021-4034)         actually pkexec (SUID), not kernel, but "universal root"
nf_tables (CVE-2024-1086)      use-after-free -> LPE
OverlayFS (several)            CVE-2021-3493, CVE-2023-0386
Sequoia (CVE-2021-33909)       seq_file overflow -> root

Dirty COW and Dirty Pipe are the best known for their very wide reach and relative reliability.

Exploitation flow (carefully)

1. uname -a -> exact version
2. LES / searchsploit -> candidates
3. Verify the exploit applies (version, arch, mitigations)
4. PREFER known, well-tested exploits (Dirty Pipe is usually stable)
5. Compile on the target or port the binary (mind glibc/arch)
6. Run -> ideally in a lab/snapshot first
7. Confirm root (id) and stabilize

Compiling on the target requires gcc; if absent, compile on a machine with the same environment or use compatible precompiled binaries.

For the defense

• Keep the kernel patched (unattended-upgrades, livepatch/kpatch to avoid reboots): the #1 defense.
• Active mitigations: KASLR, SMEP/SMAP, kernel.unprivileged_userns_clone=0, kernel.kptr_restrict, lockdown.
• Reduce surface: disable unnecessary modules/functionality, seccomp, AppArmor/SELinux.
• EDR that detects kernel-exploit patterns; monitor suspicious compilations/executions.
• Grsecurity/hardened kernels in critical environments.

Testing checklist

• uname -a + distro → exact version and architecture
• LES / searchsploit to map exploits
• Verify applicability (version, arch, mitigations)
• Having exhausted configuration paths first (Linux Privilege Escalation)
• Prefer stable exploits (Dirty Pipe, etc.)
• Test in a lab/snapshot before the real target
• Confirm root and stabilize the shell
• Blue: patched kernel, mitigations, EDR?

References

• linux-exploit-suggester — The-Z-Labs (GitHub)
• dirtypipe.cm4all.com
• HackTricks — Privilege escalation
• Exploit-DB