How LinPEAS reports kernel information

Where it appears in the output#

Kernel checks are in the System Information section (system_information). With -V or -a, LinPEAS can also send a package/kernel inventory to an online service for vulnerability lookup (an outbound request — see is LinPEAS safe?). The embedded exploit registry works offline: it matches your kernel version string against known-exploitable ranges.

╔══════════╣ Operative system
Linux 5.4.0-42-generic x86_64
╔══════════╣ Kernel Exploit Registry
Possible CVE-XXXX-YYYY (verify patch level!)
╔══════════╣ Protections
AppArmor: enabled (enforce)   SELinux: disabled

How to read a kernel finding#

• The kernel version line is factual — note the exact string including the distro suffix (-generic, .el8).
• A registry match (“possible CVE-…”) means the version falls in a known-vulnerable range. It does not mean the exploit works here.
• The protections lines (AppArmor/SELinux, ASLR, mitigations) tell you how hard exploitation would be even if a CVE applied.
• Loaded modules matter too — a vulnerable third-party module can be exploitable even on a patched kernel.

Reproduce the checks manually#

uname -a; cat /proc/version          # exact kernel string
lsmod | head -20                      # loaded modules
cat /sys/kernel/debug/x86/* 2>/dev/null | head  # mitigations (if debugfs)
# Debian/Ubuntu: check the real patch level
dpkg -l | grep linux-image
apt list --installed 2>/dev/null | grep linux-image

Verifying a registry match (do this before anything else)#

1. 1

2. 2

3. 3

4. 4

If you must test a kernel CVE (authorised lab only)#

• Use a snapshot-backed VM you can roll back — never the original.
• Prefer read-only proofs first (does the vulnerable code path exist?).
• Match the exploit to the exact kernel build and architecture.
• Have console access — if it panics, you need to see why and restore.
• Famous examples researchers study in labs: Dirty COW (CVE-2016-5195), PwnKit is polkit not kernel (CVE-2021-4034), Dirty Pipe (CVE-2022-0847). Study their write-ups before touching code.

How to fix kernel findings (defensive)#

• Patch kernels promptly; enable unattended upgrades (Ubuntu) or equivalent so security kernels apply automatically.
• Consider live patching (Canonical Livepatch, KernelCare, kpatch) to close the reboot gap.
• Track CVEs against your distro package version, not the upstream version string.
• Remove unnecessary kernel modules and disable module loading where possible (kernel.modules_disabled=1).
• Keep userspace hardened — most real-world escalations never need a kernel exploit.
• Re-run LinPEAS after patching; registry matches should clear once the build is fixed.

Concepts: AppArmor, SELinux. Related: is LinPEAS safe?, reading the output.

Kernel CVEs researchers study in labs#

These are the cases most often referenced in training material — study their write-ups in a lab to understand why version-matching is unreliable, not as a shopping list:

Notice the pattern: each was fixed by vendors quickly, which is exactly why a version-based flag on a maintained distro is so often a false positive.

Live patching: closing the reboot gap#

The riskiest window is between a patch release and the next reboot. Live-patching services apply kernel security fixes without rebooting:

• Canonical Livepatch (Ubuntu) — free for up to 5 machines, covers critical CVEs.
• KernelCare / TuxCare — cross-distro commercial live patching.
• kpatch / kGraft — the upstream mechanisms distros build on.
• Live patching covers security fixes, not every bugfix — reboots into new kernels are still needed on a schedule.

uname vs package version: which to trust#

uname -r shows the running kernel; the package manager shows the installed one. After a kernel update without a reboot, they disagree — and the running (old, vulnerable) kernel is what matters:

uname -r                          # running kernel
dpkg -l | grep linux-image        # installed (Debian/Ubuntu)
rpm -q kernel                     # installed (RHEL-likes)
# if they differ: the host needs a reboot (or live patching)

• LinPEAS reports the running kernel — match CVEs against that, not the installed package.
• A pending reboot after a security update is itself a finding: the fix is installed but not active.
• Uptime plus an old running kernel on a maintained distro usually means reboots are being deferred — flag it.

Module parameters worth a glance#

Beyond the version string, LinPEAS lists loaded modules — occasionally the vector is not the kernel itself but a third-party module (out-of-tree drivers, virtualization guest tools). A module you do not recognise, with no owning package (modinfo -F filename points outside the package tree), is worth a closer look in any authorised audit.