12 min read Steffen Pfendtner

Kernel CVE Batch Analysis: August 15, 2026 (848 CVEs, 338 awaiting NVD scores)

CVE triageLinux kernelProduct security

On August 15, 2026, the Linux kernel CVE stream published 848 CVEs in a single day. That number is not an estimate: the batch contains 848 unique CVE IDs, with the August 16 entries above it and the August 13 entries below it in the KernelScan dataset.

NVD had already scored 510 of the 848 at analysis time. The remaining 338 use KernelScan provisional assessments derived from the upstream fix and crash fingerprint. This post covers the whole batch, not just either scoring subset. The useful question is which of these reach the product you ship: its kernel configuration, architecture, hardware, exposed interfaces, attacker classes, and maintained branch.

The batch at a glance

The effective severity breakdown across all 848 CVEs is 130 Critical, 394 High, 238 Medium, and 86 Low. The provenance matters: NVD supplies 129 of the Critical and 381 of the High scores, while KernelScan supplies the still-missing score for one Critical, 13 Highs, all 238 Mediums, and all 86 Lows.

Across the complete batch, the effective vectors classify 176 as network-reachable, 60 as adjacent, 578 as local, and 34 as physical. The 524 entries rated 7.0 or higher split into 174 remote, 47 adjacent, and 303 local. Those groups answer different product questions, so the triage below is organised around reachability rather than a flat score ranking.

The subsystem spread also shows why one global priority is not useful. Using the affected-component path, 377 CVEs are in drivers, 198 in networking, 120 in filesystems, 43 in architecture code, 38 in sound, and 37 in core kernel code, with the remainder in security, memory management, headers, libraries, virtualisation, and io_uring.

Important: this is a mixed-provenance snapshot. NVD may revise its 510 scores, and the 338 KernelScan assessments will be replaced as official scores arrive. Product reachability — whether the code and trigger exist on the shipped device — remains the deciding layer either way.

The standouts: seven 10.0s, seven different product filters

Seven entries carry an effective 10.0, but the identical number hides very different exposure. Two are in the Geneve receive path: CVE-2026-72407 and CVE-2026-72408, both Critical 10.0. A remote peer can drive out-of-bounds access through GRO, but only when the host has a Geneve tunnel configured. The gate is CONFIG_GENEVE; both were introduced in 7.0 and fixed in 7.1.5 and mainline 7.2-rc1.

CVE-2026-74475, Critical 10.0, is narrower again: it needs the VXLAN DOVE route-short-circuit feature and a precisely timed neighbour update. KernelScan's risk record limits the impact to overlay packet misdelivery, not memory corruption or privilege escalation. The fix is in 6.6.151, 6.12.103, 6.18.44, 7.1.8, and mainline 7.2-rc6.

CVE-2026-74309, Critical 10.0, crosses a more valuable trust boundary: a guest or container assigned a vDPA device backed by a Marvell Octeon endpoint can corrupt host memory through a non-contiguous IRQ map. The filter is specific Octeon endpoint hardware plus vDPA assignment; systems without both do not expose the path.

The last three demonstrate why the vector is only the start of triage. CVE-2026-74279 and CVE-2026-74280, both Critical 10.0, are DMA cleanup bugs in Cavium and Marvell OcteonTX crypto drivers. Their practical trigger is a local user exercising the kernel crypto API on that hardware, leading to DMA resource exhaustion. CVE-2026-72421, Critical 10.0, is an IPv4 FIB policy bypass reachable through network namespaces: error routes can be ignored when no custom FIB rules exist. None of the three is generic remote code execution simply because the headline score reads 10.0.

The high-rated CVEs, grouped by where they bite

The 524 CVEs rated 7.0 or higher are too numerous for a useful line-by-line article. The product-shaped summary is smaller: exposed kernel services, storage fabrics and gateways, nearby devices and radios, and local or guest workloads.

Remote kernel services and storage fabrics

The NFS/SUNRPC server cluster is the first place to look on storage appliances. CVE-2026-72217 (Critical 9.8) is an attacker- controlled out-of-bounds write while decoding NFS RPC writes. CVE-2026-72220 (Critical 9.8) is a double-free reached by a sequence of valid and malformed RPC requests, while CVE-2026-72221 and CVE-2026-72222 (both Critical 9.8) race the server-side TLS handshake. All four require a kernel RPC service such as NFS to be exposed; the practical gates are CONFIG_NFSD, CONFIG_SUNRPC, and TLS use for the handshake pair.

The in-kernel SMB server is another distinct surface. CVE-2026-72044 (Critical 9.8) lets an unauthenticated client overflow a stack buffer during ksmbd multichannel session binding, and CVE-2026-74521 (Critical 9.1) can bind a new channel to another client's authenticated SMB3 session. Both disappear when CONFIG_SMB_SERVER is absent; exporting shares with userspace Samba is a different code path.

NVMe-oF and SCSI split by target and initiator. On the target side, CVE-2026-72129 (Critical 9.8) lets an RDMA client drive an enormous out-of-bounds read when inline data exceeds a page, and CVE-2026-72130 (Critical 9.8) is a heap write in DH-HMAC-CHAP authentication. On the initiator side, CVE-2026-74556 (Critical 9.8) lets a malicious iSCSI target overflow the client's command-response buffer. The gates are role- specific: CONFIG_NVME_TARGET_RDMA, NVMe target authentication, and CONFIG_ISCSI_TCP respectively.

Network gateways, overlays, and policy enforcement

Gateways should start with policy-bypass and helper paths, not every networking row. CVE-2026-74569 (Critical 9.8) is reachable only when a firewall forwards SIP over TCP through the conntrack/NAT helper. CVE-2026-72320 and CVE-2026-72348 (both Critical 9.1) affect narrow nftables catchall-inversion and ip6tables extension-header rule shapes. Their score matters, but the decisive evidence is whether the product loads those helpers and actually deploys the affected rules.

Protocol and overlay gates cut more of the queue. A reachable SCTP endpoint exposes CVE-2026-74287 (Critical 9.1), an out-of-bounds parameter read from an unauthenticated INIT or ASCONF chunk; no CONFIG_IP_SCTP means no path. Geneve and VXLAN matter to cloud and container networks, while most sealed appliances build neither. That configuration distinction is more useful than treating all 174 network-vector highs as equally reachable.

Adjacent devices, WiFi, and Bluetooth

Of the 47 high-rated adjacent-vector CVEs, 16 are in Bluetooth and 18 are in WiFi or mac80211 paths. The Bluetooth group includes CVE-2026-74541 and CVE-2026-74540 (both High 8.8), use-after-free bugs in ISO and L2CAP connection handling. The WiFi side includes CVE-2026-74554 (High 8.8) in ath12k peer handling, CVE-2026-74489 (High 8.8) in mac80211 aggregation, and CVE-2026-72003 (High 8.8) in brcmfmac frame processing.

The remaining adjacent entries sit in specialised fabrics and devices including Thunderbolt, CAN, batman-adv, RDMA, Xen, WWAN, and DMA engines. This is not one generic "nearby attacker" bucket. Resolve it by radio or bus presence, then by the exact driver: CONFIG_BT or CONFIG_MAC80211 only opens the first door; the shipped chipset decides the rest.

Local privilege escalation, containers, and guest-to-host boundaries

The 303 local high-rated entries dominate the batch numerically and matter most on multi-tenant systems. Four 9.3s show the host-isolation risk clearly: CVE-2026-72288 and CVE-2026-72289 (both Critical 9.3) corrupt host memory through arm64 KVM's virtual interrupt controller; CVE-2026-74568 (Critical 9.3) is another arm64 VGIC race; and CVE-2026-74517 (Critical 9.3) is a use-after-free in x86 KVM delayed-EOI teardown. Architecture, GIC generation, CONFIG_KVM, and whether guests are untrusted decide their priority.

Container and local-sandbox products should review CVE-2026-74476 (Critical 9.1), where traffic over a veth pair with XDP can crash the host, plus BPF memory-safety paths such as CVE-2026-72111 (High 8.8), CVE-2026-72423 (High 8.8), CVE-2026-72426 (High 8.4), and CVE-2026-74256 (High 8.4). Here the gate is not merely CONFIG_BPF_SYSCALL; it is whether the workload can load the relevant BPF program or reach the sockmap/XDP path under the product's namespace, capability, LSM, and sysctl policy.

Appliance triage: where to start by product type

  • Storage, HCI, and NAS products: start with NFS/SUNRPC, ksmbd, NVMe-oF target, iSCSI initiator, and the filesystem cluster. Separate target-facing network clients from hostile storage servers; they are opposite attacker directions.
  • Network gateways and telecom equipment: review the SIP conntrack helper, nftables/ip6tables rule shapes, SCTP, and configured Geneve/VXLAN overlays. Confirm whether packets traverse the kernel dataplane or bypass it through an ASIC, NPU, userspace stack, or DPDK.
  • Multi-tenant hosts and hypervisors: prioritise KVM/VGIC, vhost, SR-IOV/vDPA/IOMMU, BPF, veth/XDP, and namespace-crossing bugs. A guest or local workload crossing into the host is the boundary the product sells.
  • Container platforms: resolve BPF and network-namespace paths using the actual runtime policy: unprivileged BPF settings, user namespaces, capabilities, seccomp, LSM policy, and whether CNI attaches XDP to veth devices.
  • Embedded, mobile, and wireless products: intersect the 377 driver CVEs with the device tree, buses, and shipped hardware. Bluetooth and WiFi deserve attention where present; on a headless wired appliance they usually disappear as a block before version analysis starts.

A useful example: four VXLAN CVEs, one config decision

Four direct VXLAN entries show how one configuration gate can clear several alarming scores: CVE-2026-74475 (Critical 10.0), CVE-2026-74473 (Critical 9.8), CVE-2026-74474 (Critical 9.8), and CVE-2026-74406 (Critical 9.8). If CONFIG_VXLAN is absent, all four are not affected by configuration. If VXLAN is built but the product never creates a VXLAN device, the trigger remains absent at runtime.

Where VXLAN is configured, the cluster splits again. The first two need DOVE route short-circuiting and network traffic through that overlay. The header-pull issue also depends on DOVE extensions, IPv6 proxy, or multicast-database support. The GRO receive race instead needs a local actor able to create and destroy VXLAN sockets while injecting packets — typically CAP_NET_ADMIN, potentially inside a permitted user namespace.

Four CVEs become three product decisions: is VXLAN compiled, is an affected overlay feature configured, and can the required remote or local attacker reach it. That is a reviewable answer; "kernel version in range" is not.

Medium and low still matter

The 238 Medium and 86 Low entries complete the batch; they are not excluded from the analysis. Among the Mediums, 130 are in drivers, including 27 network drivers, 18 GPU drivers, nine device- mapper/MD paths, and a long tail through hardware monitoring, Bluetooth, SCSI, accelerators, input, I2C, InfiniBand, CXL, DMA, MMC, USB, and platform code. Outside drivers, the Mediums include 35 filesystem, 26 networking, 14 sound, 11 architecture, and 11 core-kernel entries.

For the right product, a Medium in exactly the storage, GPU, sensor, audio, or network driver the device depends on outranks a Critical in a protocol it never builds. The 86 Lows are narrower still, but they receive the same configuration, hardware, and attacker-path test before being closed. Severity orders the work; it does not decide applicability.

Compliance output should say why

For customers, auditors, and procurement teams, "we looked at all 848 CVEs" is 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, protocol, or attacker class is absent.
  • 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.

Score provenance belongs in the evidence, too: 510 entries currently use NVD scores and 338 use KernelScan provisional scores. That distinction should not change whether a product-specific not-affected justification is defensible.

How KernelScan helps with this batch

KernelScan is built for this scale. Upload the product's kernel .config, select its version and architecture, and KernelScan narrows all 848 CVEs to code the product can build. Hardware, exposed services, namespace and capability policy, storage roles, radio presence, and guest trust then decide which attacker paths remain. The result is a product queue spanning Critical through Low, not a queue restricted to whichever source happened to publish a score first.

The fixes landed in several waves. The batch records include stable releases 5.10.261, 5.15.212, 6.1.178, and later points 6.6.151, 6.12.103, 6.18.44, and 7.1.8; mainline fixes span 7.2-rc1 through 7.2-rc6. Use each CVE's branch-specific mapping rather than pretending one minimum version describes all 848. If a certified product cannot move immediately, configuration and reachability are how the real patch order is decided.