LES: heuristics that guess your kernel's exposure to public exploits

A single shell script and three text files

The repository is four entries: linux-exploit-suggester.sh, README.md, LICENSE and CHANGELOG. There is no build step, no package manager metadata and no test directory. Getting the tool is a single file fetch, and the command in the README saves it under a shorter name:

wget https://raw.githubusercontent.com/mzet-/linux-exploit-suggester/master/linux-exploit-suggester.sh -O les.sh

Worth noticing: that URL is built from the mzet- path while the project now lives under The-Z-Labs, so the quick download command and the repository name point at different paths. Anyone pinning a copy for a scan pipeline should note which path it came from.

The tool is GPL-3.0. Two companion resources sit outside the repository: a write-up about usage and inner workings at blog.z-labs.eu, and les-res, a separate repository that holds the hardening feature analyses and the files the output links to. The script itself is the only executable thing here, which is the whole deployment story.

Four exposure states, and the one you never see

Exposure is the core judgement the tool makes, and it uses four labels. Highly probable means the assessed kernel is most probably affected and there is a very good chance a proof of concept works out of the box without major modifications. Probable means it may work but most likely needs customization to suit your target. Less probable means additional manual analysis is required to verify whether the kernel is affected. Unprobable means the kernel is highly unlikely to be affected, and here is the catch: that state is not displayed in the tool's output.

So a run that prints nothing is not a certificate. It means nothing scored better than unprobable against the entries in the script, and the script is a shell file that has to be updated as new CVEs are published.

The four labels also mean the output is a ranking, not a verdict. The README is explicit that exposure is calculated using heuristics, and the detailed method is described in the linked write-up rather than in the repository. Reading a list of highly probable entries as a confirmed vulnerability list is the fastest way to waste an engineer's afternoon.

Every finding carries a Tags expression and a Comments precondition

The shape of one finding is more instructive than the count of them. Each entry leads with a [+] marker and a bracketed CVE identifier plus a short name, then adds four lines: Details with a link explaining the bug, Exposure with the label, Tags with a distribution and kernel expression, and a Download URL pointing at exploit-db, followed by a Comments line that states a precondition.

The Comments line is the part people skip and the part that decides the outcome. The example for the eBPF verifier bug reads that CONFIG_BPF_SYSCALL needs to be set and kernel.unprivileged_bpf_disabled is not 1. Both are sysctl and build time conditions the tool is reasoning about, not conditions it has exploited. That is the difference between a hit and a working privilege escalation.

The Tags field is a compact regular expression, and it is the mechanism that makes the heuristic cheap to run. It encodes distributions and kernel version families in one string, so a single pattern can stand for debian 9.0 on kernel 4.9.0-3-amd64, fedora 25, 26 and 27, and a spread of ubuntu releases on 4.4, 4.8 and 4.10 kernels. That is also why the label is only ever a probability: matching a pattern tells you the kernel looks like a known vulnerable one, nothing more.

--checksec reads compile time and run time in one pass

The second feature checks kernel hardening. It verifies both the compile time configurations and the run time sysctl values, which the project argues gives a more complete picture of a running kernel's posture than build flags alone. The framing is deliberate: the mode is described as a modern continuation of the --kernel switch in checksec.sh by Tobias Klein.

The output groups findings under mainline kernel protection mechanisms and gives each a state in brackets, a human name and the CONFIG macro it corresponds to. A disabled GCC stack protector support line carries the CONFIG_HAVE_STACKPROTECTOR macro, and every entry is followed by a link to a per-feature analysis file inside the les-res repository. Each finding therefore comes with the reasoning attached, which is better than a bare pass or fail.

The limitation sits in what the array holds. A feature appears in this output only after somebody has analysed its source code and added it to the FEATURES array in the script, with the write-up published under features in les-res. Coverage is therefore a function of past volunteer work. A kernel with a hardening measure that nobody has analysed simply produces no line, and a missing line is silence rather than a pass.

The uname switch audits a kernel you are not standing on

There are three documented invocations, and the difference between them decides what kind of question you can ask. The bare run assesses the machine it executes on. The checksec run reports the security features of that same machine. The third takes a uname string, which the README describes as the output of uname -a, and assesses exposure of a Linux kernel to publicly known exploits based on that string instead of the local one:

./linux-exploit-suggester.sh
./linux-exploit-suggester.sh --checksec
./linux-exploit-suggester.sh --uname "$(uname -a)"

This example uses the local `uname -a` output; replace it with a quoted, captured output string from the target to assess a remote inventory. That third mode is what turns a single file into something you can point at an inventory. You can hold a list of hosts, feed their uname output through it, and rank which machines look exposed without touching the machines themselves. It is also the mode with the widest gap between what it reports and what it knows, because a version string is all it has. It cannot see sysctl state, cannot see which CONFIG options the running kernel actually honoured, and never checks the Comments preconditions, because none of that travels in uname -a.

A fourth thing follows from the design: this is a triage and ranking tool. It surfaces candidates and their preconditions; it does not attempt exploitation, and nothing in it confirms a kernel is vulnerable.

Tags, Rank and ext-url are how the list stays current

The contributing section is really a schema description, because the data model of this tool is the data model a new exploit has to fit. Contributors are asked to add newly published privilege escalation exploits, and to test existing ones across distributions and kernel versions, recording the result as a Tags entry such as:

ubuntu=12.04{kernel:3.(2|5).0-(23|29)-generic}

Read as documented, that tag means the exploit was verified to work correctly on Ubuntu 12.04 with kernels 3.2.0-23-generic, 3.2.0-29-generic, 3.5.0-23-generic and 3.5.0-29-generic. When a matching tag is found, the tool highlights the entry and bumps a dynamic Rank. The Tags string is therefore the whole knowledge base: no tag, no ranking.

The second data type is ext-url, for a proof of concept someone has adapted to run on other kernels, because published exploits are often written for a single distribution and kernel. The third is the FEATURES array for hardening measures. With one acknowledged contributor named for frequent work, you can see the update rate this design implies: every new kernel family and every new CVE is manual.

Last push on 2026-03-20, no tagged releases

The repository is not archived and the last push landed on 2026-10-20. It has no GitHub releases at all, so there is no version number to pin and nothing to compare against. A CHANGELOG file exists at the root, and the detailed write-up the README points to sits at a URL dated 2019/05/10, which is the reference for how the exposure heuristics were described.

That combination is the honest maintenance picture: a single file whose contents decide its accuracy, updated by hand as CVEs appear, with no release history to consult before a scan run. For an auditor that is workable if you know the tool is old, and misleading if you assume a recent commit means a current exploit list. The kernel version string you are auditing is the only freshness signal in play.

The two checks worth making before trusting a report are both cheap. Compare the CVE identifiers it prints against what your vulnerability process already tracks, so you can see immediately whether the list is behind your own. And check whether the hardening measures you care about appear in the checksec output, because the ones nobody analysed are the ones you will not see. Beyond that, the tool is a fast first pass, and the write-up it cites is where the method is.

Editorial conclusion

Take LES when you want a fast triage pass over a fleet of machines, or a second opinion next to a hardening checklist, because it runs from one downloaded file and needs nothing installed. Do not take it as a vulnerability verdict: a finding states highly probable rather than confirmed, an empty report is not a clean bill because the unprobable case is never printed, and the linked proofs of concept are often written for one kernel on one distribution. Before you act on a result, check three things: whether the kernel.unprivileged_bpf_disabled and CONFIG_BPF_SYSCALL style preconditions in the Comments line hold on the host you care about, whether the Tags expression matches your distribution and kernel string exactly, and whether the hardening features you care about appear in the output at all, since a measure is reported only once somebody has analysed it and added it to the FEATURES array.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. The-Z-Labs/linux-exploit-suggester on GitHub