Linux Kernel Exploitation: Know the Attack Surface

In 2024, CVE-2024-1086 — a use-after-free bug in the netfilter subsystem — let local users escalate to root on kernels from 5.14 to 6.6. Same story, different year. Linux kernel bugs keep appearing, and attackers who understand the attack surface get there first. This post walks you through how to map kernel exposure on a live system and what that information actually tells you.

Step One: Know What Kernel You Are Running Against

Everything starts with version fingerprinting. Before any exploit attempt, an attacker needs the exact kernel version, architecture, and build flags. Defenders need that same information to know which CVEs apply.

# Logged in as devops@prod-web-01 (192.0.2.45)
$ uname -a
Linux prod-web-01 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

$ cat /proc/version
Linux version 5.15.0-91-generic (buildd@lcy02-amd64-059) 
(gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) 
#101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023

That output tells you the exact kernel release, the compiler used to build it, and the SMP flag confirming symmetric multiprocessing is enabled. SMP matters because race-condition exploits like dirty pipe variants behave differently on multi-core systems.

An attacker cross-references 5.15.0-91-generic against public databases like kernel.org changelogs or searchsploit. A defender runs the same check fleet-wide using something like ansible all -m command -a 'uname -r' and flags anything below the patched baseline.

Step Two: Map Exposed Kernel Interfaces

The kernel exposes attack surface through syscalls, loaded modules, and special filesystems like /proc and /sys. Modules are the biggest variable — a vulnerable out-of-tree driver can undermine an otherwise patched kernel.

$ lsmod | grep -E 'nf_|netfilter|xt_'
nf_tables              212992  0
nf_conntrack          180224  2 nf_nat,nf_tables
nf_nat                 57344  1 nf_tables
xt_MASQUERADE          20480  1
nf_reject_ipv4         16384  1 nf_tables

$ cat /proc/sys/kernel/unprivileged_userns_clone
1

That lsmod output shows nf_tables is loaded with no active users — meaning it is present but idle. That is exactly the module CVE-2024-1086 lives in. If you see it loaded on a system running an affected kernel version, the exploit path is open.

The second line is critical. unprivileged_userns_clone set to 1 means unprivileged users can create user namespaces. Namespaces are a force-multiplier for kernel exploits — they let an attacker access interfaces like nf_tables without root. Hardened systems set this to 0. Many Ubuntu installs ship it enabled by default.

An attacker seeing both conditions — vulnerable module loaded, user namespaces open — knows they have a clean exploitation path. A defender seeing this output has two immediate actions: patch the kernel or disable user namespaces as a temporary control.

Step Three: Audit Syscall and sysctl Exposure

Beyond modules, the attack surface includes kernel parameters that weaken memory protections. Tools like checksec (a shell script that reads ELF headers and kernel settings) give you a fast read on the security posture of both binaries and the running kernel.

$ checksec --kernel
* Kernel protection information:

  Description - IS ENABLED
------------------------------------------------------
  GCC stack protector support:            Yes
  Strict user copy checks:                No
  Restrict /dev/mem access:               Yes
  Restrict /dev/kmem access:              Yes
  grsecurity / PaX:                       No
  Exec Shield:                            No
  Writing to outside task segments:       No
  SMEP (kernel):                          Yes
  SMAP (kernel):                          Yes
  Kernel Address Space Layout Randomization (KASLR): Yes
  LKRG (Linux Kernel Runtime Guard):      No

Read this output like a scorecard. SMEP and SMAP are on — good, that blocks basic ret2user attacks where you redirect kernel execution into user-space shellcode. KASLR is on — good, but it is bypassable with an information leak, and the output shows no LKRG runtime integrity guard to catch exploitation in progress.

Strict user copy checks are off. That means the kernel does not enforce boundaries on copies between user and kernel memory as aggressively as it could. Combined with a heap overflow in the right subsystem, that matters.

An attacker reading this output knows: KASLR needs a leak primitive first, ret2user is blocked so they need a ROP chain or kernel heap technique, and there is no runtime detection. A defender reading the same output prioritizes enabling strict user copy checks (CONFIG_HARDENED_USERCOPY=y) on the next kernel build and evaluates LKRG deployment.

What To Do Now

Pick one production Linux host you manage. Run checksec --kernel and cat /proc/sys/kernel/unprivileged_userns_clone right now. If user namespaces are enabled and you do not have a specific application requirement for them, disable them immediately with sysctl -w kernel.unprivileged_userns_clone=0 and make it persistent in /etc/sysctl.d/99-hardening.conf. That single change closes the namespace-based exploitation path for a wide class of kernel CVEs — including the netfilter bugs that have dominated the last two years.