Three separate Linux kernel vulnerabilities, disclosed years apart and patched in entirely different subsystems, have all landed on CISA's Known Exploited Vulnerabilities catalogue within the same twelve-month window — a reminder that "the kernel" is not one attack surface but dozens of them, all sharing the same trust boundary between unprivileged users and root.
| CVE | CVSS | Subsystem | Added to KEV |
|---|---|---|---|
| CVE-2021-22555 | 8.3 | netfilter x_tables (heap out-of-bounds write) | 6 Oct 2025 |
| CVE-2018-14634 | 7.8 | create_elf_tables() (integer overflow) | 26 Jan 2026 |
| CVE-2026-31431 | 7.8 | algif_aead crypto API (resource transfer) | 1 May 2026 |
Same privilege boundary, three unrelated failure modes
What makes this cluster worth reading as a set rather than three isolated advisories is the diversity of the underlying bugs. CVE-2021-22555 is a heap out-of-bounds write in netfilter's x_tables code reachable through user namespaces — NVD describes it as allowing an attacker to "gain privileges or cause a DoS (via heap memory corruption) through user name space," a vector that has been a recurring theme in kernel privilege-escalation research precisely because unprivileged user namespaces intentionally expose a large amount of kernel code to unprivileged callers. CVE-2018-14634 is a much older and structurally different bug: an integer overflow in create_elf_tables(), the routine that lays out the initial stack when the kernel executes a new binary, which NVD notes could let "an unprivileged local user with access to SUID (or otherwise privileged) binary" escalate privileges. CVE-2026-31431 is different again — a fix description in the kernel's own changelog frames it as reverting an unsafe in-place-operation optimization in algif_aead (the AF_ALG crypto API), restoring out-of-place copying because "there is no benefit in operating in-place... since the source and destination come from different mappings." Three subsystems — packet filtering, process loading, and crypto — with nothing in common except that each one crosses the exact line between what an unprivileged process can touch and what only root should be able to touch.
That is the actual pattern here: the kernel's privilege boundary is enforced independently, subsystem by subsystem, by whoever wrote that subsystem's code. There is no single choke point to fix once. Every new subsystem, every new namespace, every new syscall path is a fresh place where the boundary has to be re-implemented correctly, and this cluster is what it looks like when it isn't — three times, in three unrelated corners of the codebase, over a span of roughly eight years of original disclosure dates before consolidating into the same KEV window.
Why local privilege escalation matters even when nothing is "remote"
None of these three CVEs is a remote, unauthenticated vulnerability by itself — CVE-2018-14634 explicitly requires "an unprivileged local user with access to SUID (or otherwise privileged) binary," and the other two similarly presuppose some form of local code execution first. It is tempting to file local privilege escalation bugs as lower priority than remote code execution, but that reasoning breaks down in exactly the environments where Linux dominates: multi-tenant cloud hosts, containerized workloads sharing a kernel across tenants, and CI/CD runners executing untrusted code from pull requests. In every one of those settings, "local" access is precisely what an attacker gets first — through a compromised container, a malicious build script, or a web application vulnerability that yields a low-privilege shell — and a kernel privilege-escalation bug is the difference between that foothold staying contained and it becoming full root on the host.
What to check this week
Confirm kernel patch levels across the full fleet, not just internet-facing hosts. All three of these bugs are local privilege escalation vectors, meaning the hosts that matter most are shared infrastructure — container hosts, CI runners, and multi-user systems — not just perimeter-facing servers.
Prioritize systems that run untrusted or third-party code, since local privilege escalation is only dangerous where an attacker can already get some form of local execution; CI/CD runners and shared development environments deserve particular attention here.
Treat CVE-2021-22555 as the highest-priority of the three given its 8.3 CVSS score and its reachability through user namespaces, a feature increasingly enabled by default for container tooling.
Audit which kernel versions are actually in production, since these three CVEs affect different, sometimes very old, kernel version ranges — a single "patch the kernel" ticket without checking version applicability risks leaving one or two of the three unresolved.
A closing note on the long tail of kernel disclosure-to-KEV timing
CVE-2018-14634 was originally disclosed in 2018 and only added to KEV in January 2026 — nearly eight years later. That gap does not mean the bug sat unexploited the whole time; it means confirmed in-the-wild exploitation was only recently established, likely against systems that never applied the original 2018 patches. Old kernel CVEs do not expire; they wait for an unpatched fleet.
A final consideration on shared-kernel risk models
Organizations running container platforms, Kubernetes nodes, or CI infrastructure should treat "the kernel" as a single shared attack surface across every workload on a host, since a privilege escalation bug in any subsystem — networking, process execution, or cryptography — potentially breaks the isolation model the entire platform depends on.
How Safeguard helps
Safeguard's continuous inventory tracks kernel versions across the full fleet — cloud hosts, container nodes, and CI runners alike — so that a privilege escalation disclosure like any of these three surfaces immediately against the systems that are actually running the affected code, rather than waiting for a manual audit to catch up with a patch that was available years earlier.
