Home > Linux

OS Version & Kernel Info

Linux version and kernel information are foundational for any Linux pentest. Accurate identification tells you which exploits may work, which mitigations are present, what features and drivers exist, and how to safely proceed. This tutorial explains how to discover, interpret, and act on OS and kernel data; how to map versions to vulnerabilities; and practical guidance for hardening, detection, and forensic considerations.

Why OS and Kernel Info Matter

The kernel is the security boundary between user-space and hardware. Kernel version, modules, compile options, and distribution-specific patches determine:

  • Which public CVEs are applicable.

  • Which privilege-escalation or container-escape techniques can succeed.

  • Whether kernel hardening features are enabled (e.g., module signing, KASLR).

  • Which exploit payloads and binaries will run on the target architecture.

  • How risky an operation is for system stability and forensic traceability.

Always collect accurate information before attempting any kernel-level testing or exploits.

Basic Commands: Quick Identification

Use these commands to get authoritative OS and kernel facts.

Identify distribution and release:

cat /etc/os-release
lsb_release -a
cat /etc/*release

Identify kernel version and architecture:

uname -r
uname -v
uname -a
uname -m

Inspect full kernel build and compiler info:

cat /proc/version

Show uptime and load (helps infer patch cadence):

uptime

Practical example: uname -r might print 5.15.0-89-generic. That string is the single most useful immediate kernel identifier.

Interpreting OS Release Data

/etc/os-release returns fields like NAME, VERSION, ID, and VERSION_CODENAME. Use them to:

  • Determine vendor (Ubuntu, Debian, CentOS, RHEL, Fedora).

  • Decide whether to use apt, yum, or dnf commands for package checks.

  • Map distribution-specific kernel builds (vendor kernels may include backports or custom patches).

Legacy files such as /etc/issue, /etc/debian_version, /etc/redhat-release can be useful on older systems.

Detailed Kernel Inspection

Get kernel release string and full output:

uname -r        # release
uname -v        # build and date
uname -a        # full line (kernel, arch, host, date)

Inspect kernel config (if available):

zcat /proc/config.gz               # if kernel exposes it
cat /boot/config-$(uname -r)       # common location on many distros

Check loaded modules and drivers:

lsmod
modinfo <module-name>

List kernel command-line options from bootloader:

cat /proc/cmdline

Examine kernel messages from boot (shows KASLR, mitigations, module signing info):

dmesg | less
dmesg | grep -i kaslr
dmesg | grep -i "mitigation"

Architecture and CPU Details

Architecture affects payload compatibility and exploit selection.

Check CPU architecture:

uname -m            # example: x86_64, aarch64, i686
cat /proc/cpuinfo

Check for virtualization or container markers:

systemd-detect-virt
grep -i "docker\|lxc\|kubepods" /proc/1/cgroup

Kernel Modules, Capabilities, and Device Interfaces

Enumerate modules to spot risky drivers or unused surfaces:

lsmod
for m in $(lsmod | awk 'NR>1{print $1}'); do modinfo $m | sed -n '1,4p'; done

Check file systems and device nodes that may be abused:

mount
cat /proc/filesystems
ls -la /dev | less

Look for writable device files or unusual block devices which could be leveraged for kernel attacks.

Kernel Hardening & Compile-Time Options

Kernel config reveals enabled protections. Look for options such as:

  • CONFIG_RANDOMIZE_BASE / KASLR

  • CONFIG_MODULE_SIG / module signature enforcement

  • CONFIG_DEBUG_INFO (debug symbols present)

  • CONFIG_SECCOMP / seccomp support

  • CONFIG_SECURITY_SELINUX / CONFIG_SECURITY_APPARMOR

If /proc/config.gz or /boot/config-$(uname -r) is absent, consider installing kernel debug packages or fetching vendor kernel sources for comparison.

Checking Kernel Mitigations & CPU Vulnerabilities

Linux exposes CPU and mitigation status under /sys/devices/system/cpu/vulnerabilities/. Check them:

ls /sys/devices/system/cpu/vulnerabilities
for f in /sys/devices/system/cpu/vulnerabilities/*; do echo "== $f =="; cat "$f"; done

This shows status for Spectre, Meltdown, MDS, L1TF, and other CPU mitigations where applicable.

Distribution Package-Level Kernel Info

Find installed kernel packages and their versions:

Debian/Ubuntu:

dpkg -l | grep linux-image
apt-cache policy linux-image-$(uname -r)

RHEL/CentOS/Fedora:

rpm -qa | grep kernel
dnf list installed kernel

Knowing the package name and vendor patch level helps map the kernel release string to vendor security advisories.

Mapping Kernel Version to CVEs

Kernel exploits target very specific version ranges. Steps:

  1. Record exact kernel string (uname -r, uname -v, /proc/version).

  2. Record distro and package build (dpkg -l or rpm -qa).

  3. Use local exploit databases (searchsploit) or online CVE databases to search by kernel version and distribution. Example commands:

searchsploit linux kernel 5.15

  1. When researching, match both kernel version and vendor build (Ubuntu’s -generic builds may differ from plain upstream kernels).

Common historical examples (for illustration):

  • DirtyCow (CVE-2016-5195) targeted specific kernel ranges.

  • DirtyPipe (CVE-2022-0847) affected Linux 5.8+ in certain configurations.

Do not attempt kernel exploits on production systems without authorization; they can crash systems and corrupt data.

Tools for OS and Kernel Enumeration

Useful tools and packages:

uname, lsb_release, cat /etc/os-release
lsmod, modinfo
dmesg
readelf, objdump (to inspect binaries and modules)
apt, dpkg, rpm, dnf (package managers)
searchsploit or exploitdb (local exploit searching)
cve-search, vulners-cli (if available)
uname -r and /boot listings

Install exploitdb on Debian-based systems:

sudo apt install exploitdb
searchsploit dirtypipe

Practical Examples with Expected Output (interpreting results)

Example: uname -r -> 5.15.0-89-generic
Interpretation steps:

  • 5.15.0 indicates kernel major/minor/patch level.

  • -89-generic is the vendor/distribution build. Use dpkg -l | grep linux-image to get corresponding package name and build date.

  • Search 5.15.0-89-generic on vendor security pages or exploit databases to find vendor-adapted CVEs and patches.

Example: cat /proc/version might show the GCC version used to build the kernel; that helps when compiling compatible kernel modules or exploit payloads.

Safe Research Workflow

  1. Collect kernel and distro details and save to a report.

  2. Check vendor advisories and apt list --upgradable / dnf check-update.

  3. Use exploit databases to find known, applicable CVEs.

  4. Prefer testing exploits on disposable lab VMs with the same kernel build.

  5. If manual exploit tests are needed, snapshot the VM before running.

  6. Never run kernel exploits on production systems without explicit, written authorization.

Hardening and Mitigations (What Defenders Should Check)

  • Keep kernels updated using vendor patches; prefer LTS kernels with vendor backports.

  • Enable secure boot and kernel module signature verification.

  • Disable unused kernel modules and blacklist drivers not required.

  • Enforce SELinux/AppArmor policies; verify they are in enforcing mode.

  • Use mount options: nosuid, nodev, noexec for untrusted filesystems.

  • Harden sysctl settings (network, ptrace restrictions). Example:

sudo sysctl -w kernel.yama.ptrace_scope=1
sudo sysctl -w fs.protected_hardlinks=1
sudo sysctl -w fs.protected_symlinks=1

  • Monitor kernel module loads and dmesg for unexpected messages.

  • Use host-based integrity tools (AIDE, tripwire) and kernel-level detection (auditd) to log suspicious activity.

  • Limit use of sudo and review /etc/sudoers for unsafe entries.

Detection and Monitoring Guidance

  • Audit modprobe and /sbin/insmod usage.

  • Watch /var/log/kern.log and dmesg for anomalies.

  • Use auditd to log syscalls related to module loading and ptrace.

  • Monitor /sys/devices/system/cpu/vulnerabilities/ for mitigation changes after updates.

  • Use SIEM rules around package updates, kernel upgrades, and unexpected reboots.

Forensics and Evidence Preservation

  • If testing reveals a potential kernel exploit or compromise, preserve /var/log/, /proc/, /sys/, and dmesg outputs.

  • Create memory dumps and disk images before performing destructive tests.

  • Record commands run, timestamps, and snapshots to retain reproducible evidence.

  • Avoid actions that overwrite logs (e.g., rebooting) until evidence is collected.

When to Fetch Kernel Source or Headers

  • When compiling proof-of-concept exploits, install matching kernel headers:

sudo apt install linux-headers-$(uname -r)

  • For deep analysis, fetch vendor kernel source or upstream kernel tree to inspect vulnerable code paths.

Quick Cheat-Sheet: Commands Summary

# OS info
cat /etc/os-release
lsb_release -a

# Kernel info
uname -a
cat /proc/version
cat /boot/config-$(uname -r)   # if present
zcat /proc/config.gz          # if present

# Architecture
uname -m
cat /proc/cpuinfo

# Modules and devices
lsmod
modinfo <module>

# Package-level kernel listings
dpkg -l | grep linux-image
rpm -qa | grep kernel

# Mitigations
ls /sys/devices/system/cpu/vulnerabilities
dmesg | grep -i kaslr

# CVE/exploit search
searchsploit <keyword>        # exploitdb/searchsploit

Intel Dump

  • Kernel and OS identification is required before any exploit research.

  • Use cat /etc/os-release, lsb_release -a, and cat /etc/*release for distro data.

  • Use uname -r, uname -a, and cat /proc/version for kernel details.

  • Kernel config reveals compile-time hardening features (/proc/config.gz or /boot/config-*).

  • Architecture (uname -m) determines payload compatibility.

  • Enumerate modules (lsmod, modinfo) and device nodes (/dev) for attack surface.

  • Check /sys/devices/system/cpu/vulnerabilities for CPU mitigation status.

  • Map exact kernel strings and vendor package builds to CVEs; minor versions and vendor patches matter.

  • Use dpkg/rpm to find kernel package names and patch levels.

  • Always test kernel exploits in an isolated lab with snapshots.

  • Harden by enabling secure boot, module signing, SELinux/AppArmor, and appropriate sysctl settings.

  • Monitor kernel logs, audit module loads, and preserve forensic artifacts if compromise is suspected.

HOME LEARN COMMUNITY DASHBOARD