Kernel CVE Batch Analysis: June 24, 2026 (219 CVEs, none scored by NVD)

On June 24, 2026, the Linux kernel CVE stream did the thing it now does several times a month: it dumped a whole month's worth of fixes at once. 219 kernel CVEs published in a single day — and at the time of this triage, not one of them carried an NVD CVSS score. Every severity label below is a KernelScan provisional assessment, computed from the upstream fix and crash fingerprint while the official scoring queue catches up. They exist so product teams have something to sort on today instead of staring at 219 blank severity fields.

The useful question is never "are there 219 CVEs?" Product builders already know kernel CVEs arrive by the truckload. The useful question is which of them can reach the product you actually ship: its kernel configuration, its architecture, its exposed interfaces, the attacker classes it allows to exist, and the stable branch it tracks. This post does the first pass of that sorting and points at the handful worth opening this week.

The batch at a glance

KernelScan's provisional breakdown for the 219 CVEs is 1 Critical, 39 High, 162 Medium, and 17 Low. None of the 219 had an NVD CVSS score in the KernelScan dataset at analysis time.

Forty of them land at or above 7.0. That group splits in a way that maps straight onto product exposure: 18 are remotely reachable (a packet or a peer triggers them), one more is adjacent-network (a Bluetooth pairing path), and 21 are local — an attacker who can already run unprivileged code on the box. Those two halves answer to completely different product questions, so the triage below is organised around them rather than around a flat score ranking.

Important: this is early triage. NVD, downstream vendors, and product-specific threat models may later disagree on severity — that is normal and expected. The goal here is to separate realistic product exposure from version-string noise while the official scoring queue catches up, not to pre-empt it.

The one Critical: a remote, unauthenticated storage-target bug

CVE-2026-52989: NVMe-oF TCP target uninitialised read, Critical 9.6

The single Critical in the batch is the one to look at first, because it needs nothing local. A remote NVMe-over-TCP initiator can send a malformed H2C data PDU with an out-of-bounds length or offset, and the target kernel then reads subsequent network data through an uninitialised iterator — kernel memory corruption and a panic, with no authentication and no privileges required. The vulnerable code is the in-kernel NVMe target TCP transport (CONFIG_NVME_TARGET_TCP), and the fix is in every maintained branch (including 6.6.141, 6.12.91, 6.18.33, 7.0.10, and mainline 7.1).

The product filter here is unusually clean. If your product is an NVMe-oF / NVMe-over-TCP storage target — a SAN, a storage appliance, a hyperconverged node exporting block storage — and that target port is reachable by untrusted initiators, this is the week's priority. If you only ever act as an NVMe initiator, or you don't build the target side at all, the code isn't compiled and this is a documented not affected.

The high-rated CVEs, grouped by where they bite

The remaining 39 high-rated CVEs fall into four product-shaped clusters. For each, the first pass is the same: is the subsystem compiled in, and can the attacker it needs even exist on this device?

Storage and clustered-filesystem appliances

Beyond the NVMe-oF Critical, this batch is heavy on bugs that only matter if your kernel speaks a clustered storage or file-serving protocol. The standout is a cluster of five libceph CVEs in the in-kernel Ceph client — CVE-2026-52955 (CRUSH map decode OOB, High 8.6), CVE-2026-52956 (CephX auth-reply OOB, High 8.5), CVE-2026-52958 (OSD map OOB, High 8.2), CVE-2026-52957 and CVE-2026-52954 (CRUSH choose-args, High 7.5) — all reachable from a malicious or compromised Ceph server (or a man-in-the-middle on the cluster network). Alongside them: CVE-2026-53043 (OCFS2 DLM query-region OOB, High 8.1) from a peer cluster node; CVE-2026-53046 and CVE-2026-53010 (ksmbd async-crypto and durable-reconnect UAFs, High 7.5/7.1) in the in-kernel SMB server; CVE-2026-52967 (SMB client symlink loop, High 7.6); and CVE-2026-53021 (SCSI target UNMAP overflow, High 7.1). Each is gated by a specific CONFIG_* — CONFIG_CEPH_LIB, CONFIG_OCFS2_FS, CONFIG_SMB_SERVER, CONFIG_CIFS — that a single-purpose appliance very often does not build.

Remote network-transport bugs

The second remote cluster lives in the networking stack and triggers on crafted traffic. CVE-2026-52924 is an SCTP use-after-free (High 8.6): a remote peer sends a Stale-Cookie ERROR during association setup, no authentication required — relevant anywhere SCTP is enabled (telecom/SIGTRAN signalling, some clustering). CVE-2026-53006 is an ICMPv6 receive-path UAF (High 7.9) reachable by any remote host that can send your box IPv6. CVE-2026-53091 panics the GSO path on a crafted segmentation-offload packet (High 8.2). CVE-2026-52986 is an out-of-bounds read in the netfilter SIP connection-tracking helper (High 8.1), and CVE-2026-53002 is a stack buffer overflow in the SIP NAT helper (High 7.5) — both squarely a concern for VoIP gateways and firewalls that load the netfilter SIP helpers (nf_conntrack_sip / nf_nat_sip). Rounding out the group: CVE-2026-52993 (TIPC double-free, High 7.0) and CVE-2026-52939 (RDS masked-atomic null-deref, High 7.5) — both niche transports that, like RDS so often does, only matter where the module is actually loadable.

Local privilege escalation

Twenty-one of the high-rated CVEs are local: they need an attacker who can already run unprivileged code, which makes them the priority for multi-tenant hosts, container platforms, CI runners, and anything that runs customer or third-party workloads. The densest knot is six BPF CVEs, most of them verifier-soundness bugs that let a crafted program do what the verifier thinks it can't: CVE-2026-53081, CVE-2026-53092, CVE-2026-53090 (verifier bypasses, High 7.7-7.8), CVE-2026-53095 (kprobe-write-ctx bypass, High 7.8), CVE-2026-53094 (XDP-offload UAF, High 7.1), and CVE-2026-53078 (sock-ops OOB read, High 7.1). The exposure here is governed less by CONFIG_BPF_SYSCALL — nearly everything builds it — than by whether unprivileged BPF is reachable (the kernel.unprivileged_bpf_disabled sysctl, user namespaces, container policy). Right beside them, CVE-2026-53005 is an AF_UNIX SOCKMAP garbage-collector UAF (High 7.8) in the same local-BPF threat model, and CVE-2026-52943 is the MSG_ZEROCOPY use-after-free (High 8.4) in core networking that an unprivileged user can turn into reliable root — we pulled that one apart in a companion deep dive — including why "affected" comes down to whether the one config option and module that expose it are even present in your build.

Confidential computing, virtualization, and hardware

CVE-2026-52959 (High 8.4) inverts the usual trust direction: a malicious or compromised hypervisor returns a crafted certificate length to an AMD SEV-SNP guest and corrupts the guest's page allocator (CONFIG_SEV_GUEST). It only matters if your product is a confidential VM that treats the host as untrusted — but if it is, that's the entire point of the deployment. CVE-2026-52969 is a KVM dirty-ring OOB (High 7.0) for hosts exposing that interface to guests. The remaining highs are hardware- and driver-specific and resolve almost entirely on whether the part is present: CVE-2026-52987 (amdgpu user-queue double-free), CVE-2026-52951 / CVE-2026-52950 (drm/xe dma-buf UAFs), CVE-2026-53072 and CVE-2026-53073 (Bluetooth HCI lifecycle bugs, one adjacent-network, one local), CVE-2026-52934 (batman-adv mesh TVLV overflow), CVE-2026-53075 (PPP unattached ioctl bypass), CVE-2026-53025 (Greybus raw cdev UAF), and CVE-2026-53117 (s390 CIO driver-override UAF, mainframe-only).

Appliance triage

For product teams, the practical ordering comes from interface and workload exposure: who can talk to the box, and who can run code on it.

Storage and HCI appliances: start with CVE-2026-52989 if you export NVMe-oF/TCP targets, and the libceph / OCFS2 / ksmbd cluster if the kernel itself speaks Ceph, OCFS2, or SMB to peers you don't fully control.
Network appliances, gateways, and firewalls: review the netfilter SIP pair (CVE-2026-52986, CVE-2026-53002) where VoIP traffic reaches conntrack, plus SCTP, ICMPv6, and GSO wherever untrusted packets hit the Linux stack rather than an ASIC/NPU/DPDK dataplane.
Multi-tenant and workload-running hosts: prioritise the BPF verifier cluster, AF_UNIX SOCKMAP, and the zero-copy root where untrusted local code, containers, or unprivileged BPF are in scope.
Confidential-computing VMs: review CVE-2026-52959 for AMD SEV-SNP guests that treat the hypervisor as hostile.
Embedded, GPU, and wireless products: resolve the driver-specific highs (amdgpu, drm/xe, Bluetooth, batman-adv, Greybus, PPP) by whether the hardware and its CONFIG_* are present at all.

A useful example: five Ceph CVEs, one config decision

The libceph cluster is a clean illustration of why configuration-aware triage beats counting CVEs. Five separate high-rated entries (52955, 52956, 52958, 52957, 52954) all live in the same place: the kernel's client code for talking to a Ceph cluster, reached when it parses OSD maps, CRUSH maps, or CephX auth replies from the server.

That gives every one of them the same two-part reachability test. First, is the in-kernel Ceph client even compiled (CONFIG_CEPH_LIB — pulled in by CephFS CONFIG_CEPH_FS or the RBD block device CONFIG_BLK_DEV_RBD)? A self-contained appliance that never mounts Ceph storage simply doesn't build it, and all five resolve to not affected by configuration in one stroke. Second, even where the client is present, the trigger is a malicious or compromised Ceph server (or a network attacker on the storage fabric). For an appliance that talks only to its own trusted, isolated Ceph back-end, that attacker class may not exist — which is a different, but equally documentable, VEX justification than "code absent."

Five CVEs, one or two product decisions. That is the difference between a line in a spreadsheet and an answer you can defend in a release review.

Medium and low still matter

The 162 Medium CVEs are not noise; they're just narrower. Their weight sits in drivers (the largest single bucket), the networking stack, and filesystems, with a long tail through core kernel code, architecture-specific paths, sound, block, IPC, and crypto. For the right product, several of these outrank a generic High: a Medium in exactly the camera-pipeline, sensor, or filesystem driver your device depends on is a real exposure, while a remote High in a protocol you never compiled is not.

This is where kernel CVE management becomes product engineering rather than spreadsheet work. A kernel version can be in range while the vulnerable subsystem is not compiled, the device tree cannot instantiate the driver, the hardware is absent, or the only trigger requires an attacker class your product does not expose. Every one of those is a defensible not affected — and every Medium that survives those filters is a real item for the queue.

Compliance output should say why

For customers, auditors, and procurement teams, "we looked at the 219 CVEs" is far weaker than a concrete VEX statement per CVE: a status and a justification.

Affected: the vulnerable code is compiled and the attacker path is reachable.
Not affected: the required CONFIG_*, architecture, driver, hardware, or protocol path is absent — or the attacker class the CVE needs cannot exist on this product.
Under investigation: the version and configuration match, but product reachability is not yet proven.
Mitigated or fixed: the product carries the upstream fix, a downstream backport, or a documented configuration mitigation.

That is the difference between "219 new kernel CVEs" and an answer a product team can defend.

How KernelScan helps with this batch

KernelScan is built for exactly this gap: the first hours after a kernel CVE wave, when NVD is still unscored but product teams need to know what deserves attention now. Upload the kernel .config, select the version and architecture, and KernelScan narrows all 219 to the code your product actually builds — then your product's security factors decide whether the attacker each remaining CVE needs (a remote NVMe initiator, an untrusted Ceph server, an unprivileged local user, a hostile hypervisor) is even part of your threat model. From there, the remaining work is the human product-security judgement: reachable, not reachable, mitigated, or fixed.

Want to see what that judgement looks like end to end? Our deep dive on CVE-2026-52943 — one of the local roots hiding in this very batch — walks the whole path from "core code, can't compile it out" to a specific, defensible, no-reboot mitigation.