Kernel CVE Batch Analysis: August 10, 2026 (346 CVEs, none scored by NVD)

On August 10, 2026, the Linux kernel CVE stream delivered its largest single-day batch yet this year: 346 kernel CVEs published in one 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 346 blank severity fields.

The useful question is never "are there 346 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 346 CVEs is 7 Critical, 106 High, 202 Medium, and 31 Low. None of the 346 had an NVD CVSS score in the KernelScan dataset at analysis time.

113 of them land at or above 7.0 — nearly three times the high-rated count of the 219-CVE June batch. That group splits in a way that maps straight onto product exposure: 26 are remotely reachable (a packet or a peer triggers them), 15 are adjacent-network (a WiFi or Bluetooth attacker within radio range), and 72 are local — an attacker who can already run unprivileged code on the box, or a guest VM attacking its host. Those three groups answer to completely different product questions, so the triage below is organised around them rather than around a flat score ranking.

The standouts: three 9.8s, all remote and unauthenticated

Three CVEs in this batch score a provisional 9.8 — remote, no privileges, no user interaction, full confidentiality/integrity/availability impact. They are unrelated to each other, and each has a completely different product filter.

CVE-2026-68376: SCTP AUTH HMAC list overflow, Critical 9.8

A remote peer sends SCTP association-setup packets to an endpoint configured with four HMAC identifiers, and the cookie's HMAC-algorithm storage overflows. The corruption spills into adjacent authentication state, which can lead to acceptance of invalid HMAC identifiers and an out-of-bounds read in the kernel. No authentication is required. The gate is CONFIG_IP_SCTP, and the fix landed in 6.6.148, 6.12.101, 6.18.42, 7.1.6, and mainline 7.2-rc4.

CVE-2026-68159: libceph OSDMap stack out-of-bounds write, Critical 9.8

A malicious or compromised Ceph monitor sends a crafted OSDMap whose pg_temp or pg_upmap entries exceed the maximum allowed size. The kernel client decodes it without bounds checking and copies the oversized list into a fixed-size stack array. A stack OOB write reachable from the storage fabric is about as sharp as this gets. The gate is CONFIG_CEPH_LIB, and the product question is whether your device mounts Ceph storage at all.

CVE-2026-68127: IPv6 ILA checksum-adjust use-after-free, Critical 9.8

A crafted non-linear IPv6 packet through a device with an ILA checksum-adjust-transport route triggers a use-after-free that is used for both reads and writes. This one has the cleanest secondary filter of the three: the ILA route requires administrator privileges to create. If nothing on your product ever configures an ILA route (CONFIG_IPV6_ILA), the dangling pointer is never reachable no matter what arrives on the wire.

Behind them sit four Critical 9.1s: CVE-2026-68300 (SCTP AUTH chunk-verification bypass — an unauthenticated peer injects chunks by sending COOKIE-ECHO without a preceding AUTH chunk), CVE-2026-68343 (SMB client DFS referral PathConsumed OOB read, triggered by a malicious or MITM SMB server), and CVE-2026-68160 / CVE-2026-68158 (Ceph MDS snap-trace and OSDMap OOB reads from a hostile server).

The high-rated CVEs, grouped by where they bite

The remaining 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 file-serving appliances

This batch is unusually heavy on bugs that only matter if your kernel speaks a clustered-storage or file-serving protocol. The Ceph client cluster runs to eight entries beyond the Criticals already listed: CVE-2026-68156 (CephX authorizer UAF, High 8.1), CVE-2026-68157 (CRUSH type NULL deref), CVE-2026-68155 (MonMap panic), CVE-2026-68154 (CRUSH bucket OOB, all High 7.5), and CVE-2026-68131 (RBD object-map assertion panic from a compromised OSD, High 7.5). Every one is reached from a malicious or compromised Ceph server, gated by CONFIG_CEPH_LIB / CONFIG_BLK_DEV_RBD.

The in-kernel SMB server (CONFIG_SMB_SERVER) takes a similar beating, with six ksmbd entries reachable by an authenticated SMB client: CVE-2026-68099 and CVE-2026-68097 (DACL/ACE size OOB, High 8.3), CVE-2026-68098 (DACL dedup OOB, High 8.0), CVE-2026-68100 (NT ACL rebuild OOB, High 7.6), CVE-2026-68381 (oplock-break UAF racing connection teardown, High 7.5), and CVE-2026-68083 (share-escape race letting a client resolve .. from the filesystem root instead of the share root, High 7.5). On the client side (CONFIG_CIFS), CVE-2026-68388 (High 8.1) leaks kernel heap back to a malicious server during fallocate.

Remote network-transport bugs

The second remote cluster triggers on crafted traffic and mostly costs you availability rather than control. CVE-2026-68118 (High 7.5) is the broadest: a blind off-path attacker can tear down connections in SYN-RECEIVED state with an in-window RST, bypassing the RFC 5961 validation that protects established connections — that one needs no config gate at all, only a host that accepts TCP. CVE-2026-68136 (High 7.5) panics the GRO path on an LRO-capable interface that forwards packets, and CVE-2026-68299 (High 7.5) hits a BUG_ON in the vmxnet3 driver on a crafted Geneve-encapsulated packet — relevant to essentially every Linux VM on VMware. CVE-2026-68302 (High 8.1) is a use-after-free in the AMT multicast tunnel driver reachable by UDP, and CVE-2026-68379 (High 7.5) leaks a TIME_WAIT socket on every packet failing PSP policy validation until memory runs out.

Wireless and Bluetooth: the proximity attacker

Fifteen high-rated CVEs need an attacker within radio range — a class that either exists for your product or plainly does not. The sharpest is CVE-2026-68355 (High 8.8), an out-of-bounds read in the Qualcomm ath11k receive path triggered by crafted frames from anyone in WiFi range, no privileges needed. CVE-2026-68389 (High 8.7) is a UAF in the Qualcomm Bluetooth memory-dump handler triggered by a nearby peer, and CVE-2026-68125 (High 8.8) sits in the 802.15.4 link-layer security path. The ath6kl driver alone contributes four (68199, 68352, 68353, 68198), with more in wilc1000, brcmfmac, rtl8723bs, at76c50x-usb, mac80211 (CVE-2026-68409, multi-link operation UAF) and five in the Bluetooth management/HCI layer. This entire cluster resolves on one question per driver: is that radio present and its CONFIG_* built?

Local privilege escalation and tenant isolation

The 72 local highs are where multi-tenant and virtualisation products should spend their time. Two are guest→host escape primitives: CVE-2026-68400 (High 8.8, scope-changing) lets a guest VM on an Arm FF-A platform corrupt host kernel memory through memory-sharing transactions, and CVE-2026-68128 (High 8.8, scope-changing) lets a guest holding an SR-IOV VF on an Intel E810 NIC drive an out-of-bounds write in the host's ice driver via a crafted VIRTCHNL message. CVE-2026-68093 (High 7.7) breaks VM isolation a different way — a KVM/SVM ASID generation collision after a CPU hotplug cycle leaves two guests sharing stale TLB translations.

The sandbox-escape group is just as product-relevant: CVE-2026-68171 (High 7.8) lets an arm64 tracer rewrite a syscall's first argument after seccomp has already checked the stale copy — a direct hit on container runtimes that rely on argument-based seccomp filtering; CVE-2026-68166 (High 7.3) defeats hardware CET shadow stacks via userfaultfd; and CVE-2026-68294 (High 7.8) breaks network namespace isolation for QRTR sockets. Alongside them the familiar BPF and socket surface — CVE-2026-68295 (LoongArch BPF JIT verifier mismatch giving arbitrary kernel read/write), CVE-2026-68284 (sockmap cork UAF), CVE-2026-68399 (BPF socket local-storage UAF, relevant anywhere Cilium or eBPF observability runs), and CVE-2026-68121 (PPPoE send-path UAF reachable from inside a user namespace).

Appliance triage: where to start by product type

• Storage, HCI, and NAS products: start with the Ceph client cluster (68159, 68160, 68158, 68156) and the ksmbd set (68099, 68097, 68083) if you export SMB from the kernel rather than from Samba in userspace.
• Network gateways and telecom equipment: the SCTP auth cluster (68376, 68300) is the priority wherever SIGTRAN or SCTP signalling is in the product, plus TCP RST and GRO wherever untrusted packets hit the Linux stack rather than an ASIC/NPU/DPDK dataplane.
• Multi-tenant hosts and hypervisors: prioritise Arm FF-A, ice SR-IOV, and KVM ASID — all three cross a trust boundary your product sells.
• Container platforms: review arm64 seccomp bypass, QRTR namespace escape, and the BPF socket-storage UAF where untrusted workloads or unprivileged BPF are in scope.
• Embedded, mobile, and wireless products: resolve the fifteen adjacent-network highs by whether that specific radio and its CONFIG_* are present at all — and note CVE-2026-68187, an execve loop-counter underflow that affects only nommu (CONFIG_MMU=n) builds.

A useful example: five SCTP CVEs, one config decision

The SCTP cluster is a clean illustration of why configuration-aware triage beats counting CVEs. Five separate entries in this batch — 68376 (Critical 9.8), 68300 (Critical 9.1), 68320 (High 7.8), 68162 (High 7.7), and 68161 (High 7.5) — live in the same subsystem, and four of the five are in its authentication code specifically.

That gives all five the same first-pass test: is CONFIG_IP_SCTP even built? SCTP is a niche transport — it matters enormously in telecom signalling and some clustering stacks, and not at all in the overwhelming majority of appliances, gateways, and embedded devices. Where it isn't compiled, five CVEs including a 9.8 and a 9.1 resolve to not affected by configuration in one stroke.

Where it is compiled, the cluster splits again along attacker class, and that split is worth respecting. 68376 and 68300 need a remote peer and no credentials. 68320 needs a local unprivileged user who can configure an SCTP endpoint — a completely different question, and on a closed appliance with no untrusted local code, frequently a documented not affected even though the code is present and the version is in range.

Five CVEs, 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 202 Medium CVEs are not noise; they're just narrower. Their weight sits overwhelmingly in drivers (148 of 202), and within that in GPU (50) and networking drivers (40), with media (15), USB (9), hwmon, InfiniBand, MTD, and IOMMU behind them. The remainder spreads across the networking stack (24), filesystems (10), core kernel code (9), sound, memory management, and architecture-specific paths.

For the right product, several of these outrank a generic High: a Medium in exactly the GPU, camera-pipeline, or storage driver your device depends on is a real exposure, while a Critical in a protocol you never compiled is not. The GPU concentration in particular is worth a second look if you ship anything with a display stack — and worth ignoring almost entirely if you ship a headless appliance.

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 346 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 "346 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 346 to the code your product actually builds — then your product's security factors decide whether the attacker each remaining CVE needs (a hostile Ceph monitor, an authenticated SMB client, a WiFi attacker in the parking lot, a guest VM, an unprivileged local user) is even part of your threat model. From there, the remaining work is the human product-security judgement: reachable, not reachable, mitigated, or fixed.

The whole batch is fixed in the current stable releases — 6.6.148, 6.12.101, 6.18.42, 7.1.6, and mainline 7.2-rc4/rc5. If you can take those, take them. If you can't move a certified kernel on someone else's schedule, the triage above is how you decide what actually has to move first.