Kernel CVE Batch Analysis: June 6-9, 2026 (62 CVEs)

Between June 6 and June 9, 2026, the Linux kernel CVE stream delivered a dense batch: 62 newly published kernel CVEs. At the time of this triage, KernelScan had not yet seen NVD CVSS ratings for the batch, so the severity labels below are KernelScan provisional assessments, intended to help product teams decide what to inspect first.

The useful question is not "are there 62 CVEs?" Product builders already know the answer to that. The useful question is which of them can reach the product you actually ship: its kernel configuration, its hardware, its exposed interfaces, its users, and its compliance obligations.

The batch at a glance

KernelScan's current provisional breakdown for the 62 CVEs is: 0 Critical, 9 High, 36 Medium, and 17 Low. None of the 62 had an NVD CVSS score in the KernelScan dataset at analysis time.

The nine high-rated CVEs

KernelScan currently scores nine CVEs in this batch above 7.0. For product teams, the useful first pass is to map each CVE to a concrete trigger path: local workload, access-network packet, guest VM, hardware transport, enabled subsystem, and kernel branch.

CVE-2026-46274: io_uring WorkQueue UAF, High 8.4

This is the highest-scored item in the batch. The path is local unprivileged use of io_uring, introduced in the 5.9 era and fixed in current stable updates including 6.6.141, 6.12.91, and 6.18.33. Products that allow customer workloads, plugins, containers, CI tasks, shell users, or app extensions should check whether io_uring is available to that code.

CVE-2026-46289: scatterlist iterator length handling, High 8.0

This is a scatterlist iterator bounds issue introduced in the 6.3 line and fixed in stable updates including 6.6.140, 6.12.88, and 6.18.30. The practical review is caller-driven: look for compiled and reachable kernel I/O, crypto, filesystem, or storage paths that use the affected iterator behavior.

CVE-2026-46330: net/smc ULP UAF, High 7.8

The trigger path is local socket activity involving SMC TCP ULP, introduced in the 5.17 line and fixed in 6.19.4 and mainline. Appliances with local users, plugins, containers, or tenant workloads should check whether SMC is built and whether untrusted code can reach the relevant socket APIs.

CVE-2026-46323: GRO zerocopy UAF, High 7.8

This UAF sits in GRO handling for zerocopy skbs, with affected code introduced in the 6.0 line and fixed in stable updates including 6.6.142, 6.12.92, and 6.18.34. Review hosts and appliances where local workloads, packet-processing components, or dataplane software can create or drive zerocopy networking paths.

CVE-2026-46317: KVM arm64 nested MMU race, High 7.8

This is an arm64 KVM nested-virtualization issue introduced in the 6.11 line and fixed in 6.18.35, 7.0.12, and mainline. It belongs in the virtualization triage queue for arm64 products that expose nested KVM guest behavior.

CVE-2026-46316: KVM arm64 VGIC-ITS cache UAF, High 7.6

This is another arm64 KVM issue, this time in virtual interrupt controller state. It was introduced in the 6.10 line and fixed in 6.12.93, 6.18.35, and 7.0.12. Review arm64 virtualization appliances where guest VMs can exercise VGIC-ITS state.

CVE-2026-46306: PPPoE PFC frames in the flow dissector, High 7.5

The relevant input is crafted PPPoE PFC traffic; the reported path does not require an already-active PPPoE session. This is the clearest network-appliance item in the high group: CPE, gateways, BNG/vBNG, and ISP access-network systems should check whether subscriber-side Layer-2 traffic reaches the Linux flow dissector, especially on embedded architectures with strict alignment behavior.

CVE-2026-46275: Bluetooth HCI UART lifecycle races, High 7.5

This belongs to products with UART-attached Bluetooth controllers. Embedded appliances, gateways, medical devices, handhelds, and industrial systems should check the hardware transport and driver configuration before spending time on deeper analysis.

CVE-2026-46281: vmalloc realloc bounds, High 7.1

This is an internal vrealloc_node_align() shrink/realloc overflow introduced in the 6.18 line and fixed in 6.18.27. It matters most for products on newer 6.18-based kernels where a compiled kernel path can call into that helper with attacker-influenced sizes.

Appliance triage

For product teams, the practical ordering comes from interface and workload exposure: packets that reach Linux, local code execution, guest VMs, hardware transports, and enabled kernel features.

• Network appliances: prioritize CVE-2026-46306 when PPPoE or Layer-2 access traffic can reach Linux packet parsing. Review CVE-2026-46323 where local workloads or dataplane software can exercise zerocopy/GRO paths.
• Workload-running appliances: prioritize CVE-2026-46274 where io_uring is available to untrusted local code. Also review CVE-2026-46330 if SMC is present and local socket APIs are exposed.
• Virtualization appliances: review CVE-2026-46316 and CVE-2026-46317 for arm64 KVM with the relevant guest paths.
• Bluetooth-enabled embedded products: review CVE-2026-46275 where the product has the HCI UART transport path.
• Storage, backup, and data appliances: review CVE-2026-46289 and CVE-2026-46281 by version, config, and reachable caller.

The PPPoE case is a useful example

CVE-2026-46306 is a useful example of product-specific exposure. A DSL line with a customer modem at home and a concentrator down the street is a controlled Layer-2 access network where a compromised CPE, malicious subscriber device, or misconfigured provider edge may matter.

That distinction changes the product conversation. For a consumer router, the question is whether hostile traffic can arrive from the WAN access side. For a BNG or vBNG, the question is whether subscriber traffic reaches the Linux kernel flow dissector or is handled by an ASIC, NPU, DPDK path, or proprietary dataplane before Linux ever sees it. For neighbor-to-neighbor risk, most sane ISP access networks should isolate subscribers; if that isolation is broken, the PPPoE CVE is not the only problem.

Medium and low still matter

Several of the non-high CVEs are still important for the right product: Rockchip camera pipelines, Greybus/BeaglePlay bootloader paths, IIO pressure sensors, RDMA/rxe, device-mapper zones, AppArmor limits, nouveau, erofs, and 9p all showed up in this batch. They are good VEX candidates: either the hardware and config are present and you triage them, or they are absent and you can document the product decision.

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.

Compliance output should say why

For customers, auditors, and procurement teams, "we looked at the CVE" is weaker than a concrete VEX statement. The useful output for each CVE is 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.
• 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 "62 new kernel CVEs" and an answer a product team can defend in a release review.

How KernelScan helps with this batch

KernelScan is built for exactly this gap: the first 24-48 hours after a kernel CVE wave, when NVD may still be unscored but product teams need to know what deserves attention. Upload the kernel .config, select the version and architecture, and KernelScan narrows the batch to the code your product actually builds. From there, the remaining work is the human product-security judgement: reachable, not reachable, mitigated, or fixed.