CVSS Said 9.8. Your Kernel Config Said “Not Affected.”

In June 2026, more than eighty Linux kernel CVEs with a severity score of 8.0 or higher landed in the public feeds. Over twenty were rated 9.8 out of 10 — “critical” by the U.S. National Vulnerability Database (NVD).

If you run Linux servers, routers or embedded devices, that sounds like an emergency. For most systems it isn’t. Here is the same set of bugs, scored by three different parties:

Vulnerability	NVD says	Red Hat says (for RHEL)	What actually decides it
ksmbd crypto use-after-free (CVE-2026-53046)	9.8 — Critical	Not affected (no score at all)	Is the in-kernel SMB server even built into your kernel? On most systems: no.
netfilter MAC-match crash (CVE-2026-53131)	9.4 — Critical, “network attacker”	Moderate (7.0), “local attacker”	Only someone who can already configure your firewall can trigger it.
SCTP handshake read (CVE-2026-53246)	9.8 — Critical	Moderate (7.0)	Genuinely remote — but only if your kernel speaks SCTP, which most don’t.

Same bugs. Same code. Three very different answers — and the differences aren’t mistakes. Each party is answering a different question:

• NVD answers: “How bad could this be on the most exposed system imaginable?”
• Red Hat answers: “How bad is this on RHEL, configured the way we ship it?”
• The only question that matters to you is: “How bad is this on my kernel, built the way I built it?”

That third question is answerable — mechanically, from your kernel build configuration. Not with guesswork, and not with AI. More on that below.

Why does NVD score everything 9.8?

It’s structural, not sloppiness. Three things stack up.

1. The kernel security team refuses to publish scores — on purpose.

The Linux kernel is its own CVE Numbering Authority (CNA), and its position is that a kernel bug’s severity cannot be stated in general, because it depends entirely on how the kernel is configured and deployed. So kernel CVEs ship with a description and a fix — and no score. We think they’re right. A single CVSS number applied to a codebase with tens of thousands of build-time options is kind of broken. But it is also the common currency the entire industry runs on, so somebody fills in the blank.

2. CVSS rules mandate worst-case assumptions.

That somebody is NVD, and the CVSS specification ties their hands: the base score must assume the vulnerable component is present and reachable. Whether a driver is compiled in, whether a module ever loads, whether triggering the bug requires admin rights — all explicitly out of scope. A memory bug in networking code that parses a packet therefore scores as “network attacker, no privileges, full compromise”: 9.8, mechanically.

3. Volume forces triage by keyword.

The kernel CNA now mints thousands of CVEs per year, and NVD has been backlogged since 2024. Nobody there has time to trace whether a netfilter matching module can only be reached after an administrator installs a specific firewall rule. “Netfilter + out-of-bounds read” → critical → next ticket.

The result is a feed where the score tells you almost nothing about your exposure — which the kernel maintainers have been saying all along.

Why is Red Hat’s answer different?

Red Hat scores every CVE against one concrete deployment: RHEL as they ship it. They know which options their kernel is built with, which modules load by default, and what privileges an attacker realistically needs. That is how a “9.8 critical” becomes “Moderate” — or vanishes entirely into “Not affected” when the vulnerable code isn’t in their kernel at all.

That “Not affected” verdict is worth pausing on. It is not a lower score; it is a different kind of statement — an applicability verdict (in industry terms, a VEX statement: Vulnerability Exploitability eXchange). It is the most useful sentence a vendor can publish about a CVE, and Red Hat publishes it for exactly one kernel configuration: theirs.

Your router, your industrial controller, your cloud image, your NAS — none of them run RHEL’s kernel config. The methodology transfers; the verdicts don’t.

What this means for your triage

1. Applicability first, severity second. The first question about any kernel CVE is not “how bad?” but “is the vulnerable code in my build at all?” For a majority of headline criticals, the honest answer is no — the June ksmbd and SCTP bugs are textbook cases.
2. Worst-case scoring buries real risk. While the phantom 9.8s eat your attention, June also delivered CVE-2026-53075: a privilege-escalation bug in the PPP subsystem, “only” 8.8, local — and reachable by any unprivileged user on a default container host via user namespaces. Present in kernels since 2009. Score-sorted triage puts it behind bugs that don’t apply to you at all.
3. This is a solved problem, and it does not need AI. Whether CONFIG_SMB_SERVER or CONFIG_IP_SCTP is enabled in your kernel is a fact, recorded in the .config file every kernel is built from. Mapping a CVE’s fixed source files to the build options that compile them is deterministic, reproducible engineering — parsing build files, not consulting an oracle. The output is a verdict per CVE: affected or not affected, with the exact build option that decides it. The same input always yields the same output, and you can audit why.

That is precisely what KernelScan does: upload the .config of the kernel you actually run, and every incoming kernel CVE is checked against it — continuously, as the feed updates. The result is a standard CycloneDX VEX report where the June flood collapses to the handful of CVEs that genuinely apply to your build, ranked ahead of the noise.

If you remember one thing: the kernel maintainers are right that a context-free score is nearly meaningless — but you don’t have to choose between ignoring CVSS and drowning in it. Your kernel config is the context. Use it.

Readers who want the receipts: the technical breakdown of the example CVEs follows. Feel free to stop here — you already have the point.

Appendix: the CVEs in detail

CVE-2026-53046 — ksmbd use-after-free via async crypto (NVD 9.8 / RHEL: not affected)

ksmbd_crypt_message() in the in-kernel SMB3 server set a NULL completion callback on AEAD encryption requests and treated -EINPROGRESS — the normal return of an asynchronous hardware crypto engine — as an error, immediately freeing the request while the engine’s DMA operation was still in flight. The completion interrupt then dereferenced freed memory. Three conditions must all hold to reach it: the kernel is built with CONFIG_SMB_SERVER (ksmbd), a ksmbd share is actually running, and the crypto stack routes AEAD to an asynchronous hardware engine (the crash was on a Qualcomm SoC). On synchronous software crypto — the overwhelmingly common case — the buggy branch never executes. RHEL does not build ksmbd at all, hence Red Hat’s blanket “Not affected.”

CVE-2026-53131 — netfilter eth_hdr() out-of-bounds read (NVD 9.4 / RHEL Moderate 7.0)

Six netfilter components — xt_mac, ip6t_eui64, three ipset MAC types, and nf_log_syslog — called eth_hdr(skb) without confirming the packet came from an Ethernet device with a full MAC header. A packet on a non-Ethernet interface with matching rules active reads out of bounds — typically a crash. Notably, the bug dates to the initial git import of the kernel in 2005; it sat there for over twenty years. NVD scores it as a remote unauthenticated attacker because packets arrive from the network. But the vulnerable code only runs if a MAC-matching or MAC-logging rule is installed, and installing one requires CAP_NET_ADMIN. The realistic attacker is local, not the internet — which is exactly why Red Hat rates it Moderate.

CVE-2026-53246 — SCTP COOKIE_ECHO out-of-bounds walk (NVD 9.8 / RHEL Moderate 7.0)

When a listening SCTP server processes a COOKIE_ECHO chunk, the cached peer INIT chunk’s length field was never validated against the remaining buffer, so an inflated length walks the parser past the received data. This one is genuinely remote and unauthenticated — COOKIE_ECHO is processed during the handshake, before any association exists. Nobody disputes that. The downgrades reflect impact realism (a crash plus a limited leak, not the full remote compromise a naive 9.8 implies). And the applicability question still dominates: SCTP (CONFIG_IP_SCTP) is a telecom-signalling protocol, built as a rarely-loaded module or absent on the vast majority of general-purpose systems. If your kernel has it and you run SCTP services: patch now. Everyone else: your config already answered.

CVE-2026-53075 — the one the scores under-sell (NVD 8.8, local)

The counterweight to the three above. /dev/ppp authorized its administrative ioctls against the opener’s user namespace credentials while operating on the current network namespace — so an unprivileged local user could create a user namespace, gain CAP_NET_ADMIN inside it, and drive PPP units in the inherited, real network namespace. Introduced in 2009; fixed across every maintained stable series. On any default container host with unprivileged user namespaces enabled — which is the default — this applies to everyone with CONFIG_PPP built in. It will never top a score-sorted list. It should probably top yours.

Methodology notes

• NVD scores are the CVSS 3.1 base scores as published in the National Vulnerability Database at the time of writing.
• Red Hat data is from Red Hat’s public security data and severity classification. It appears in this article solely for comparison. KernelScan does not use Red Hat data in its analysis.
• KernelScan verdicts (affected / not affected per kernel configuration) are produced by deterministic analysis: CVE fix commits are mapped to source files, source files to the Kconfig build options that compile them, and those options are evaluated against the customer’s uploaded .config. No machine-learning component participates in this verdict; identical inputs produce identical, auditable outputs.