Select an evidence-matched Linux software or kernel exploit
Needs: Vulnerable package/kernel state, architecture, mitigations, namespaces and documented exploit-specific conditions
Shell commands
# Baseline
uname -a
cat /proc/version
cat /etc/os-release
dpkg -l 2>/dev/null
rpm -qa 2>/dev/null
sudo --version
lsmod
sysctl kernel.unprivileged_userns_clone 2>/dev/null
# Baseline
searchsploit "PRODUCT VERSION local privilege escalation"
searchsploit -x EDB_ID
searchsploit -m EDB_ID
gcc -Wall -Wextra exploit.c -o exploit
file exploit
sha256sum exploit
Match component, exact distribution/build and patch/backport state, architecture, required configuration/capabilities/namespaces, mitigations and dependencies. Review source and recovery risk. A version title or successful compilation is only a candidate. Follow public exploit adaptation.
Verify → Verify actual effective UID/host context after the exploit, keeping the reviewed source and adaptation record.
If it fails → Wrong build, missing feature or mitigation can invalidate the PoC. Choose another evidence-backed candidate rather than cycling random local exploits. More detail ↓
Explanation & examples
Select an evidence-matched Linux software or kernel exploit
- USE WHEN
- Permission/credential paths are insufficient and an exact affected build/configuration is present
- STARTING ACCESS
- A verified Linux foothold with a known effective UID, groups and filesystem context
- RESULT
- A justified local exploit test and independently verified privilege result
Recognize the clue
Collect distribution build/package/architecture and the required local feature before comparing a specific advisory/PoC.
uname -a
cat /etc/os-release
getconf LONG_BIT
Kernel release: KERNEL_RELEASE
Distribution package/build: VENDOR_BUILD
Required vulnerable feature: not yet verifiedMeans: A version-associated advisory is a candidate; backports and feature state determine applicability.
Confirm: Collect uname and the distribution's package/build plus architecture. Match the advisory's vulnerable feature and vendor patch status before choosing a PoC; try a confirmed sudo/file/credential route first when one exists.
- After validation
- Affected code/configuration and compatible reviewed PoC are established: select its bounded test.
- Ruled out in this context
- The vendor build includes the fix or required feature is absent: reject that exploit.
- Still inconclusive
- A release string without patch/configuration evidence leaves vulnerability unconfirmed.
Troubleshooting: Wrong build, missing feature or mitigation can invalidate the PoC. Choose another evidence-backed candidate rather than cycling random local exploits.
Match component, exact distribution/build and patch/backport state, architecture, required configuration/capabilities/namespaces, mitigations and dependencies. Review source and recovery risk. A version title or successful compilation is only a candidate. Follow public exploit adaptation.
Why it works
Kernel release strings can hide patched distributions. A matching CVE needs affected code/configuration and compatible exploit assumptions; a crash is neither success nor proof that another build will work.
Worked example · hypothetical
Observation: an automated tool names a kernel CVE. Test: compare the distribution patch/build and required feature. Illustrative output: the vendor build includes the fix. Interpretation: reject the candidate and return to unexamined permissions/applications.
New identity, privilege, host or route? Re-enumerate → All topic tasks →