Linux Kernel Exploitation: Know the Attack Surface

In 2022, CVE-2022-0847 — dubbed Dirty Pipe — let any unprivileged user overwrite read-only files and escalate to root on kernels from 5.8 to 5.16.11. It lived in a pipe buffer flag that nobody had audited properly. Understanding why that surface exists is how you stop the next one.

Step 1: Map the Kernel Version and Exposed Interfaces

Before you can exploit or defend anything, you need to know exactly what kernel you’re dealing with. Run this on the target box:

uname -r && cat /proc/version
# Output on dev-web01 (192.0.2.45):
5.15.0-91-generic
Linux version 5.15.0-91-generic (gcc version 11.4.0) #101-Ubuntu SMP

That version string is your starting point. Cross-reference it against the CVE database immediately — kernel 5.15 carries dozens of known vulnerabilities, several with public PoC exploits. Older enterprise systems running 4.x kernels are in even worse shape.

Next, enumerate what attack surface the kernel is actively exposing. The kernel talks to userspace through syscalls, device files, procfs, sysfs, and network sockets. Check which legacy interfaces are loaded:

ls -la /dev/ | grep -E 'mem|kmem|port'
# On dev-web01:
crw-r----- 1 root kmem   1, 1 Jul 31 2026 mem
crw-r----- 1 root kmem   1, 2 Jul 31 2026 kmem
crw-rw-rw- 1 root root   1, 8 Jul 31 2026 random

/dev/mem and /dev/kmem expose physical and virtual kernel memory directly. If an attacker lands a shell as any user in the kmem group, they can read kernel memory structures and potentially locate exploit targets without triggering typical detection. A defender’s first move: confirm CONFIG_STRICT_DEVMEM=y is set in the running kernel config at /boot/config-$(uname -r).

Step 2: Identify Vulnerable Syscall Paths and Kernel Modules

The kernel’s syscall interface is the widest door into ring 0. Attackers chase integer overflows, use-after-free bugs, and type confusion in syscall handlers. The first practical step is enumerating loaded modules — each one adds kernel-mode code that may not have been audited as rigorously as the core:

lsmod | awk '{print $1}' | head -20
# On dev-web01:
Module
nf_conntrack
nf_nat
ip_tables
overlayfs
vboxdrv
bluetooth
rfcomm
bnep

That vboxdrv module stands out immediately. VirtualBox kernel modules have a history of local privilege escalation bugs — CVE-2023-21987 is one example. bluetooth and rfcomm mean BlueBorne-class attack surface is live even if no Bluetooth device is connected. For an attacker on this box, these modules are priority targets for fuzzing or known-CVE matching.

Now check whether unprivileged users can load additional modules — a misconfiguration that dramatically widens the surface:

sysctl kernel.modules_disabled
kernel.modules_disabled = 0

sysctl kernel.unprivileged_bpf_disabled
kernel.unprivileged_bpf_disabled = 0

unprivileged_bpf_disabled = 0 is a serious finding. eBPF — the extended Berkeley Packet Filter — is a powerful in-kernel virtual machine. It’s also produced some of the most reliable kernel exploits of the last five years: CVE-2021-3490, CVE-2022-23222, CVE-2023-2163. Unprivileged eBPF means any local user can load and run kernel-mode bytecode. On a production server with no containerized workloads that need it, this should be locked down immediately.

Step 3: Check KASLR, SMEP, and Mitigation Bypass Potential

Modern kernels ship with exploit mitigations. But knowing which ones are actually active — not just compiled in — is what separates paper security from real security. Check the running state:

cat /proc/cpuinfo | grep -E 'smep|smap|pti'
# flags: ... smep smap pti ...

dmesg | grep -i 'kaslr\|randomize'
[    0.000000] KASLR enabled
[    0.000000] Randomized base address: 0xffffffff92e00000

KASLR randomizes the kernel’s base address at boot. SMEP prevents the kernel from executing userspace pages. SMAP prevents the kernel from accessing userspace memory directly. These are good — but none are insurmountable. Dirty Pipe bypassed all of them because it never needed code execution; it just overwrote memory through a legitimate kernel path.

The presence of these mitigations tells you what exploitation techniques are ruled out. No KASLR leak means an attacker needs a separate info-leak primitive before a control-flow hijack works. No SMEP means ret2user attacks are still viable. Map what’s missing, and you know what exploit primitives are still on the table.

Attacker’s logic: KASLR + SMEP + SMAP active? Look for data-only attacks like Dirty Pipe, or chain a kernel info-leak (e.g., from a proc file or eBPF verifier bug) before attempting RIP control.

What To Do Now

Pick one system you’re responsible for and run this single command right now:

sysctl kernel.unprivileged_bpf_disabled kernel.modules_disabled kernel.dmesg_restrict kernel.kptr_restrict

If any value comes back as 0 where you expect 1, you have an exposed attack surface that costs nothing to fix. Set kernel.unprivileged_bpf_disabled=1 in /etc/sysctl.d/99-hardening.conf and reload with sysctl --system. Do it before you close this tab.