As of this week, 19,691 of the 20,096 Linux kernel CVEs in the KernelScan database carry an assessment from the KernelScan Engine: every CVE that has a known fix commit, from 2005 through last week’s disclosures.
What that means in practice: for each of those CVEs, KernelScan can now answer the three questions a product security team actually has.
- Is the vulnerable code in my kernel at all?
- What is the bug, and who can reach it?
- Given how my device is deployed, does that attacker exist?
This post walks through the three, with real CVEs. First, why you need them.
Too many CVEs to read, written for the wrong audience
Since the kernel project became its own CVE Numbering Authority in 2024, it has published thousands of CVEs a year, compared with about 150 a year before.
Sorting by score doesn’t cut the pile down much. More than 44 % of all kernel CVEs are rated High or Critical.
And the record itself is written by kernel developers, for kernel developers. This is the official text of CVE-2023-4623, a bug in the traffic-control scheduler:
If a class with a link-sharing curve (i.e. with the HFSC_FSC flag set) has a parent without a link-sharing curve, then init_vf() will call vttree_insert() on the parent, but vttree_remove() will be skipped in update_vf(). This leaves a dangling pointer that can cause a use-after-free.
Correct, complete, and no help to anyone deciding whether to patch. It doesn’t say who can trigger the bug, through what, or what they gain. So: the three questions.
1. Is the code in my kernel?
KernelScan has answered this from the kernel .config since day one. The kernel
is modular, and most devices build a fraction of it. Most CVEs live in that other part.
A headless appliance has no graphics drivers. A wired industrial controller has no
Wi-Fi. And the most dangerous subsystems aren’t the biggest ones: of the 196 CVEs in
ksmbd, the in-kernel SMB server, 84 % are rated High or Critical, and
many embedded and appliance kernels don’t build it at all.
If the code isn’t built, the CVE is not affected and the other two questions never come up. For the CVEs that survive this step, the assessment takes over.
2. What is the bug, and who can reach it?
Every assessed CVE now has a risk summary (who can attack, what they need, what they gain), the affected component, a vulnerability analysis (root cause, what the fix changes, the attack surface), and an independent CVSS score and CWE. Where NVD hasn’t scored a kernel CVE, KernelScan still shows a score; where both exist, you can compare them. For higher-severity CVEs a second, independent model reviews the first one’s score and corrects it where needed.
Here is the risk summary for CVE-2023-4623, the bug quoted above:
A local attacker with CAP_NET_ADMIN privileges can exploit a use-after-free vulnerability in the HFSC traffic control scheduler to escalate privileges or crash the system. […] Exploitation requires local access and specific capabilities.
Attacker, prerequisite, outcome, and no function names. A CISO or an auditor can read it without reading C. Engineers still have the analysis and the fix commit when they need the detail.
The same holds for AI assistants. Explaining a kernel CVE from the raw record means fetching the fix commit, reading the patch, and often the surrounding C code, for each CVE. Through the KernelScan MCP server, an assistant gets the finished summary, analysis, scores, fix versions per stable branch and exploit status in one call, and can summarize a product’s whole CVE list without analyzing kernel source.
3. Does that attacker exist on my device?
The risk summary says a local user with CAP_NET_ADMIN can exploit
CVE-2023-4623. Whether such a user exists on your device is a question about the
device, not the bug. KernelScan describes a device with 67 security
factors: where it stands, how it is physically protected, which interfaces and
radios it has, what runs on it, and who can log in. For each CVE the engine selects
only the few factors that decide exploitability. Three well-known CVEs show how
different those selections are.
CVE-2024-1086, nf_tables use-after-free: the attacker is a local user
Actively exploited and on CISA’s KEV list. Triggering it needs
CAP_NET_ADMIN, which an ordinary user can obtain by creating a user
namespace. So the questions are who can run code on the device, and whether that
escalation path is blocked.
| What the engine needs to know | Factors it selected |
|---|---|
| Who can run code on the device? | ssh-remote, console-only, no-interactive-users |
| Does it run workloads from others? | untrusted-code, container-host, multi-tenant |
| What stands in the attacker’s way? | unpriv-escalation-blocked, seccomp-enabled, selinux-apparmor, kaslr-enabled |
No network, radio or physical-interface factor in that list: this bug can’t be triggered from the network. A container host running other people’s workloads is the classic target. A sealed appliance with no interactive users and unprivileged user namespaces blocked has nobody who could exploit it.
CVE-2020-12351, “BleedingTooth”: the attacker is within radio range
A type confusion in the Bluetooth L2CAP code that an unauthenticated attacker nearby can trigger, without pairing and without an account on the device.
| What the engine needs to know | Factors it selected |
|---|---|
| Is the radio on? | bluetooth-enabled |
| Can a stranger get within range? | env-public-indoor, env-public-outdoor, phys-open |
| What limits the damage? | seccomp-enabled, selinux-apparmor |
Here the user-access factors are missing, because the attacker doesn’t need a login.
Without bluetooth-enabled the bug can’t be reached at all; a device with
Bluetooth on in a public place is exactly where it matters.
CVE-2024-53104, USB video out-of-bounds write: the attacker plugs in a device
Also on the KEV list. A crafted USB camera corrupts kernel memory the moment the driver parses its descriptors, so the attacker needs a USB port, not a network connection.
| What the engine needs to know | Factors it selected |
|---|---|
| Where are the USB ports? | usb-pcb, usb-enclosure, usb-exposed |
| Can someone get to them? | phys-open |
The three USB tiers are the key part: a USB header on the circuit board inside a sealed case is a very different risk from a USB port on a public kiosk. (The engine also selected the user-access and workload factors here, so a plugged-in device isn’t the only path it considers.)
From factors to a verdict
When a product’s kernel config says a CVE is affected, the engine compares the CVE’s deciding factors with the factors you selected for the product and returns a contextual verdict with a written justification:
| Verdict | Meaning | Share so far |
|---|---|---|
| Not affected | The attacker this CVE requires doesn’t exist in your deployment. | 33.6 % |
| Increases risk | Your deployment exposes exactly the path the bug needs. | 41.2 % |
| Neutral | Your factors neither open nor close the path. | 20.7 % |
| Mitigates | A hardening measure you run makes exploitation meaningfully harder. | 4.5 % |
Across the 15,759 verdicts computed so far, about one in three config-affected CVEs is closed by deployment context. The code is in the kernel, but no attacker in your deployment can reach it. Two rules keep this honest: context never overrides the config (if the code isn’t built, the CVE stays not affected regardless of factors), and a verdict depends only on the CVE and the deciding factors, so two products in the same situation get the same answer.
The 405 we haven’t assessed, and what happens next
405 of the 20,096 kernel CVEs are not assessed, and every one of them lacks a known fix commit. 76 predate 2005, when the kernel’s git history begins, so no fix commit for them can exist; the others point to a mailing-list patch, a vendor advisory or just a version number. We analyze from the patch that fixed the bug, because that is what shows what was broken and which code path reaches it. Without it, an analysis would rest on the description text alone, which is the guesswork we’re replacing. Those CVEs keep their NVD data and are assessed as soon as a fix commit becomes known.
From here on, new CVEs are assessed automatically as they are imported, and the verdicts for your products follow. Every assessment records the engine version that produced it, and older ones are re-run when the method improves. Every verdict has a written reason you can hand to an auditor, a customer, or a market-surveillance authority under the Cyber Resilience Act. You can read every reason, and you can disagree with it. The job is to give you a reasoned first answer for every CVE, so your team spends its time on the ones where the answer is increases risk.
Try it: upload your kernel .config, select the security factors
that describe your device in the product wizard (Pro and Enterprise), and compare the
VEX report with and without context.