Kernel Exploit Triage Definition Kernel exploit triage is the process of deciding whether a Linux kernel privilege escalation vulnerability is relevant, safe to test, already patched, or better handled through remediation without exploit execution. Why it matters Kernel exploits can be high impact, but they can also crash systems, corrupt state, and produce false conclusions when distribution kernels backport fixes without changing version strings. For defenders and learners, kernel triage should be disciplined, not a reflexive "searchsploit and run it" step. How it works Use 6 triage gates: Version: kernel release, architecture, distribution, and patch level. Exposure: required configuration, namespace, capability, syscall, filesystem, or local condition. Patch status: vendor advisories and backported fixes. Exploit quality: source, reliability, compile assumptions, and crash reports. Environment risk: production versus lab, snapshot, data value, and uptime. Decision: patch, document, test in clone, or reject as not applicable. Techniques / patterns Collect kernel and distribution details before searching for exploits. Prefer vendor advisories over raw version matching. Reproduce only in disposable clones or CTF/lab hosts. Record why an exploit is not applicable. Treat kernel exploit execution as last resort. Worked example: reject a tempting exploit Lead: public exploit claims kernel 5.x local root Host: Ubuntu vendor kernel with patched package revision Precondition: unprivileged user namespaces required Host setting: user namespaces disabled Environment: production-like lab with no snapshot Decision: do not run exploit; record not-applicable evidence and patch status Good triage often ends with "do not exploit." That is still valuable security work when the decision is evidence-based. Variants and bypasses 1. False positive by version The version appears vulnerable, but distribution patches were backported. 2. Missing precondition The host lacks a required namespace, filesystem, config option, or capability. 3. Architecture mismatch An exploit assumes x86_64, specific offsets, or a compiler/toolchain unavailable on target. 4. Crash-prone proof The exploit may work but risks kernel panic or data corruption. 5. Container boundary confusion A kernel issue may affect the host, but container conditions and capabilities decide exploitability. Impact Root privilege escalation. Host crash or denial of service. Container escape preconditions. Persistence through kernel-level compromise in severe cases. Emergency patch and incident response requirements. Detection and defense Patch through vendor channels. Vendor kernels often include backports and mitigations not obvious from version strings. Reduce local attack surface. Disable unneeded features and harden namespaces, unprivileged user namespaces, and container capabilities. Use EDR/audit signals around exploit behavior. Suspicious compiler use, namespace abuse, or crash patterns may signal attempts. Snapshot before lab testing. Kernel tests should be reversible. Prefer remediation over exploit proof in production. A credible vulnerable condition plus vendor fix can be enough. What does not work as a primary defense Version string matching alone. It misses backports and config requirements. Running public exploit code blindly. That is a reliability and safety failure. Ignoring "local only" vulnerabilities. Any foothold turns local bugs into privilege escalation candidates. Practical labs Use disposable lab VMs only. Collect kernel context uname -a cat /etc/os-release sysctl kernel.unprivileged_userns_clone 2>/dev/null Capture distribution context, not only kernel version. Build a kernel triage card CVE/name: Kernel version: Distribution: Architecture: Required preconditions: Vendor patch status: Exploit source quality: Decision: This separates applicability from excitement. Check package patch metadata dpkg -l 'linux-image*' 2>/dev/null | head rpm -q kernel 2>/dev/null Use the package manager and vendor advisory path before assuming vulnerable. Decide proof level Production host: no exploit execution Staging clone: compile/test only with snapshot CTF lab: exploit allowed within rules Finding proof: version + preconditions + vendor advisory + fix The safest proof depends on the environment. Practical examples A kernel looks old, but Ubuntu backported the fix. A container lacks the capability required by a public exploit. A CTF target intentionally expects kernel exploit practice. A production server should be patched rather than exploited. A crash-prone proof of concept is rejected because configuration evidence is enough. Related notes linux-privilege-escalation linux-enumeration linux-capabilities linpeas-workflow Cloud Lab Infrastructure Suggested future atomic notes linux-kernel-hardening container-kernel-attack-surface kernel-cve-advisory-triage unprivileged-user-namespaces References Official Docs: Linux kernel security bugs — https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html Official Docs: uname — https://man7.org/linux/man-pages/man1/uname.1.html Research / Deep Dive: MITRE ATT&CK Privilege Escalation — https://attack.mitre.org/tactics/TA0004/ ← PreviousCron and Timer AbuseNext →LinPEAS Workflow Explore nearby notes Linux Privilege EscalationCron and Timer AbuseCron and timer abuse occurs when a low-privileged user can influence a scheduled task that runs with higher privileges. Linux Privilege EscalationLinPEAS WorkflowLinPEAS workflow is the disciplined use of the LinPEAS enumeration script as a triage assistant for Linux privilege escalation, followed by manual verification and... Linux Privilege EscalationLinux CapabilitiesLinux capabilities split root privileges into smaller units that can be assigned to processes or files. Linux Privilege EscalationLinux EnumerationLinux enumeration is the structured collection of local host facts that can explain privilege boundaries, misconfigurations, credentials, and escalation paths. Linux Privilege EscalationLinux Privilege EscalationLinux privilege escalation is the process of moving from a lower-privileged local account to a higher-privileged account or capability on the same Linux host. Linux Privilege EscalationPATH HijackingPATH hijacking is privilege escalation through influencing which executable or library a privileged process loads.