Kernel CVE Batch Analysis: September 16-17, 2026 (878 CVEs, 62 of them remote)

On September 16 and 17, 2026 the Linux kernel project published 878 CVEs across two days — 276 on the 16th and 602 on the 17th. The 17th alone is the largest single day in our corpus since August 15 (848), and comfortably ahead of the September 11 batch (431) we wrote up a week ago. NVD was roughly a third of the way through at analysis time: 319 of the 878 carry an NVD score, and the remaining 559 are KernelScan provisional assessments.

The severity split reads alarming and the reachability split does not. 37 Critical, 339 High, 408 Medium, 94 Low, with 376 entries rated 7.0 or higher — but only 62 of those 376 carry a network attack vector. 274 are local, 39 need radio or adjacent-network range, and one needs physical access. Across the whole batch the ratio is starker still: 719 of 878 are AV:L. This is not a remote-code-execution wave. It is a very large local-privilege and driver-hardening wave with a small, sharp remote edge in one place — network storage.

The batch at a glance

The standouts

The cleanest remote bug of the batch is CVE-2026-89969 (Critical 9.8), an out-of-bounds write in the NVMe-over-TCP target. nvmet_tcp_try_recv_pdu() reads a PDU header into a fixed 128-byte union, then computes the remaining payload length from the header’s own hlen field and reads that many more bytes into the same buffer — without bounding the result. An unauthenticated attacker who can open a TCP connection to an exposed NVMe-oF endpoint writes attacker-controlled bytes past the end of a kernel buffer. No credentials, no race, no timing window. Introduced in 5.0; fixes are listed for 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51, 7.2.5 and mainline 7.3-rc2. The gates are CONFIG_NVME_TARGET and CONFIG_NVME_TARGET_TCP — a product that consumes NVMe but never serves it does not carry this path at all.

The second standout is the batch’s top-scored ksmbd entry, and it comes with a narrower gate than its score suggests. CVE-2026-90173 (Critical 9.8) is a use-after-free in the SMB Direct transport: the completion queues are allocated with ib_alloc_cq_any(), which arms a workqueue poll handler, then torn down with ib_destroy_cq(), which frees them without cancelling that work. A remote, unauthenticated attacker races a late RDMA completion against teardown. But it only exists where ksmbd is built with SMB Direct and an RDMA provider is present — real hardware or Soft-RoCE. It is new code, introduced in 7.1, so anything on 6.x LTS cannot contain it; fixes are listed for 7.2.6 and mainline 7.3-rc1 only.

The third is where NVD and our reading part company, and it is worth walking through because the pattern repeats across this batch. CVE-2026-89778 is an out-of-bounds page-array read in the zisofs decompressor: the empty-block fast path in zisofs_uncompress_block() returns a length that ignores the incoming page offset, so the page cursor in zisofs_fill_pages() walks past the end of its array. NVD scores it 9.8, network vector, no privileges. Our provisional assessment is 6.3, local, high privileges — because the code is reached by reading a compressed file on a mounted ISO9660 image, and mounting one requires CAP_SYS_ADMIN or an automount path plus the ability to insert removable media. Both scores are defensible descriptions of different deployments — but neither is AV:N. The honest upper bound, on a device that automounts whatever is inserted, is AV:P/AC:L/PR:N/UI:N with full impact: 6.8. Automount removes the privilege requirement and still does not produce a network vector. Note also that the affected file is compiled only under CONFIG_ZISOFS (isofs-$(CONFIG_ZISOFS) += compress.o), a narrower gate than ISO9660 support itself — and one that is off in most modern defconfigs. The removable-media question gets its own section below, because it is the one place in this batch where a config audit actively misleads you.

The same split hits the on-disk filesystem parsers throughout: CVE-2026-90048 (ntfs3 attribute-list overflow, NVD 9.8 / ours 6.7), CVE-2026-89779 (ntfs3 extended-attribute record, NVD 9.1 / ours 6.0) and CVE-2026-89786 (ext4 inline-directory over-read, NVD 9.1 / ours 4.4) all need a crafted image and a mount. Twenty-two of the batch’s NVD-rated 9.0-and-above entries carry a provisional assessment at least 1.5 points lower, almost always on exactly this axis: who is allowed to hand the kernel the malformed input.

The high-rated CVEs, grouped by where they bite

Before the clusters, the shape of the 376. Ten subsystems account for 173 of them and the remaining 203 are spread thin across 92 others — but the ranking argues against itself the moment you add severity. drivers/gpu tops the list with 26 entries and not one Critical. arch/arm64 sits second from the bottom with 9, of which 5 are Critical — the nested-virtualization series. drivers/nvme is smaller still at 12 and carries 4. Volume and severity point in different directions here, and neither of them is reachability, which is why the groups below are organised by attacker position rather than by either one.

Network-reachable — 62 Highs, and 51 of them are storage

If your product does not serve or consume storage over a network, most of this batch’s remote surface disappears in one pass.

• ksmbd and SMB Direct — 23 CVEs, 16 rated 7.0+, 2 Critical. Walked through in full below.
• NFS, nfsd and SUNRPC — 16 CVEs, 12 Highs, 7 Critical. CVE-2026-90104 (Critical 9.8) corrupts state in the NFSv4.1 callback XDR decoder; CVE-2026-90151 (Critical 9.8 by NVD, our provisional 6.4) leaves a stale callback-IDR entry after a failed client allocation. The nfsd state trio CVE-2026-90038, CVE-2026-90037 and CVE-2026-90036 all sit in fs/nfsd/nfs4state.c, and 90038 specifically needs an administrator running exportfs -u to win its race — which is why our provisional read is 6.4 against NVD’s 9.8. Gates: CONFIG_NFSD for the server side, CONFIG_NFS_FS for the client.
• NVMe over Fabrics — 18 CVEs, 12 Highs, 4 Critical. Beyond the TCP PDU write above: CVE-2026-89970 (Critical 9.8) is an authentication-timeout use-after-free reachable by any initiator that starts DH-HMAC-CHAP and times the teardown, and CVE-2026-90230 (Critical 9.1) is an out-of-bounds read in the auth negotiate path. CVE-2026-89972 (NVD 9.8, our provisional 6.2) is on the host side in multipath namespace teardown and needs privileged namespace scanning, not a network peer.
• iSCSI and iSER targets — 5 Highs, 3 Critical. CVE-2026-90414 and CVE-2026-90413 (both Critical 9.1) hand received PDUs to opcode handlers without checking wc->byte_len against the declared data-segment length, so an initiator over-reads the receive descriptor — and the over-read data can reach the backing store. CVE-2026-90011 (Critical 9.1) is a one-byte terminator miscount in the iSCSI login buffer, reachable pre-authentication on a CHAP-configured portal. Gates: CONFIG_ISCSI_TARGET, CONFIG_INFINIBAND_ISERT.
• Fibre Channel — 25 qla2xxx CVEs, 13 Highs, 3 Critical. A full-driver audit pass. CVE-2026-89846 (Critical 9.1) takes rsp_info_len straight from the target’s FCP response and subtracts it from the sense-data length without a bound, so a malicious or compromised target leaks host kernel heap. That is a trusted-fabric threat model: the attacker is your storage array, not the internet. Gate: CONFIG_SCSI_QLA_FC.
• The remainder. CVE-2026-92489 (Critical 9.8 by NVD, our provisional 7.8 and local) is a double-free in the IPsec packet-offload TX path, triggered when netfilter drops a packet on an XFRM tunnel in packet-offload mode — VPN endpoints with offload-capable NICs. CVE-2026-89783 (Critical 9.8) is a secpath overrun in IPv6 IPsec input. CVE-2026-90110 (NVD 9.4, our provisional 3.6) randomises inetpeer’s RB-tree comparison with SipHash: an off-path attacker could predict the tree topology, evict targeted peers and reset their ICMP rate-limit buckets — a SAD-DNS-shaped side channel, not memory corruption, which is the whole distance between those two scores.

Radio range and adjacent networks — 39 Highs

Almost entirely wireless and peripheral drivers, and almost entirely irrelevant to a rack-mounted product. 45 wireless CVEs (21 Highs), of which 27 are mt76 alone (12 Highs, mostly 8.8) — a MediaTek driver sweep across DMA, channel handling and the MCU interface, so anything shipping an mt7915/mt7925/mt7996 radio should treat this as a driver update rather than a CVE list. 15 Bluetooth CVEs (9 Highs) including CVE-2026-90256 (High 8.8), an unlocked l2cap_data access in the disconnect-indication path reachable from a nearby device via connection timeout. Plus the HID series (CVE-2026-93189, CVE-2026-90329, both 8.8) and two NFC entries, which need a hostile peripheral in hand. Gates are per-driver and unusually effective here: an appliance with no radio and no USB HID stack drops this entire column.

Local — 274 Highs, and this is the actual story

• Virtualization escape — 28 KVM CVEs, 22 Highs, 7 Critical. The densest Critical cluster in the batch and all of it guest-to-host. Five Criticals are arm64 nested virtualization (CVE-2026-89918, CVE-2026-89916, CVE-2026-89915, CVE-2026-89914, CVE-2026-89775, all 9.3): VNCR pseudo-TLB handling where an address-rollover comparison silently skips TLB invalidation at the top of the VA space, leaving stale entries a guest can use. Two are x86 nVMX (CVE-2026-89931, CVE-2026-89930, both 9.3) — 89931 double-maps vmcs12 pages specifically when KVM was built with CONFIG_KVM_HYPERV=n, which is a config-dependent Critical in the most literal sense. Four more sit in LoongArch KVM. All of it gated on CONFIG_KVM and on nested virtualization actually being turned on; none of it applies to a product that runs no untrusted guests.
• BPF — 36 CVEs, 21 Highs, 0 Critical. A verifier and JIT hardening sweep, uniformly 7.8, uniformly local. Whether these are escalation paths or noise is entirely a question of who can load a BPF program on your box: on a container host or multi-tenant node, this is the highest-value cluster in the batch; on a sealed appliance with kernel.unprivileged_bpf_disabled=1 and no tenant workloads, it is close to inert.
• Graphics — 59 CVEs, 26 Highs, 0 Critical. The single largest subsystem block, and the one most products can dismiss wholesale. A headless appliance without CONFIG_DRM loses 59 entries in one line.
• InfiniBand/RDMA — 37 CVEs, 23 Highs (the two isert Criticals counted above), media — 43 CVEs, 18 Highs, USB — 26 CVEs, 9 Highs, sound — 20 CVEs, 8 Highs. Driver lifecycle and teardown races, mostly requiring the ability to bind, unbind or open the device.
• The core networking outlier. CVE-2026-90049 (Critical 9.3, scope-changed) is local by vector but network-triggered in practice: skb_zerocopy() calls skb_tx_error() on a source skb it does not own, completing that skb’s zerocopy uarg while it is still in flight. On an Open vSwitch host with a userspace upcall action, a packet plus memory pressure is enough, and a subsequent ESP delivery then decrypts over fragments the skb no longer owns. Introduced pre-3.11 and fixed across every maintained branch.

Appliance triage

A useful example: 23 CVEs, one config symbol, three attacker classes

Take ksmbd, the in-kernel SMB server. The batch carries 23 entries against it — 20 in the server proper and 3 in the SMB Direct transport — of which 16 are rated 7.0 or higher and 2 are Critical. That is a meaningful share of the whole batch’s remote surface sitting behind a single Kconfig symbol.

The first filter is one line. Products that use a userspace SMB server, or no SMB at all, do not compile fs/smb/server/. With CONFIG_SMB_SERVER=n, all 23 get a not-affected verdict with a code-not-present justification — not a judgement about exploitability, just an accurate statement about what is in the binary.

The second filter is one more line. Of the 23, two live in SMB Direct: CVE-2026-90173 (Critical 9.8, the batch’s top ksmbd entry) and CVE-2026-90172 (High 7.5), both unauthenticated. Both require CONFIG_SMB_SERVER_SMBDIRECT and an RDMA provider. A ksmbd product serving SMB over ordinary TCP — which is nearly all of them — drops its highest-scoring entry on the second line of the audit, while still being genuinely affected by the other 21.

Then it splits by attacker class, and this is where a config gate stops helping and a threat model has to take over. Of the 16 high-rated entries:

Same subsystem, same two days, one config symbol, and three materially different answers about who has to be standing where. A tool that sorts these 23 by CVSS gives you the SMB Direct Critical you may not even compile, at the top, above eight bugs a logged-in user on your share can reach today.

Removable media, and the config gate that lies

The batch carries 54 entries in on-disk filesystem code — parsers that run against whatever bytes are on the volume. For most products that cluster is noise. For anything with a USB port or a media slot that accepts a stick from outside the building, it is the primary attack surface in these two days, and it is the one case where CONFIG_* analysis gives the wrong answer on its own.

NTFS is the sharp edge, not ISO9660. Thirteen entries across the two NTFS drivers — 7 in ntfs3, 6 in the legacy driver — with 9 rated 7.0 or higher: CVE-2026-90048 (Critical 9.8, attribute-list heap overflow), CVE-2026-89779 (Critical 9.1, extended-attribute over-read into getxattr()), CVE-2026-90199 (High 7.8, an integer wraparound that defeats the VCN bounds check), and on the legacy side CVE-2026-90133 (High 7.8) and CVE-2026-90118 (High 7.8). That matters more than the isofs Critical for a simple reason: a stick handed to you by a stranger is overwhelmingly likely to be NTFS or FAT, and almost never a zisofs-compressed ISO9660 image.

Two of them do not wait for anyone to open a file. CVE-2026-89782 (High 8.4) and CVE-2026-89781 (High 8.4) both sit in fs/ntfs3/fslog.c and fire during journal replay at mount time. An NTFS volume that was not cleanly unmounted replays its log on the next mount, which is exactly what a crafted image declares itself to be. Insertion is the whole interaction. Everything downstream — whether a file manager indexes the volume, whether anything reads a file — is irrelevant.

The same shape repeats across the other image parsers: CVE-2026-93095 (High 7.8, hfsplus catalog out-of-bounds write), CVE-2026-90203 (High 7.1, a negative Squashfs block offset), CVE-2026-90161 (High 7.1, EROFS ztailpacking), CVE-2026-90419 (High 7.1, an nilfs2 super-root inode size) and CVE-2026-89786 (Critical 9.1, the ext4 inline-directory over-read). Each needs a crafted image and a mount, and nothing more.

Why the config gate lies here. Everywhere else in this batch, an unset symbol is a clean not-affected: nothing compiles ksmbd into a product that does not serve SMB. But an appliance that offers firmware update or config import from a USB stick enables CONFIG_NTFS3_FS on purpose, so that a stick formatted on a Windows laptop works — and then ships a udev rule or a small daemon that mounts whatever appears. The symbol is on for a documented product reason, the mount happens without a human decision, and the attacker is anyone who can reach the port. A sweep that resolves these on code presence alone marks them not-affected and is wrong.

Worth being precise about what “automount” means on such a device: it is almost never udisks2, which is session- and polkit-driven and generally absent on a headless box. It is a mount-on-insert path the vendor wrote deliberately. So the triage question is not “is a desktop automounter installed” — it is “did we build a path that mounts untrusted media, and what does it accept?” A product that mounts only its own signed update images, verified before mount, has a genuinely different answer from one that mounts any volume the kernel can probe.

Medium and low still matter

The 502 entries below 7.0 are where product-specific judgement lives, and they are overwhelmingly driver code: 331 of the 502 in drivers, led by 37 in networking drivers, 33 GPU, 25 media, 17 USB, 16 firmware, 14 InfiniBand, 14 SCSI, 11 md and 10 block. The other 171 split across fs (52), net (42), arch (25), kernel (21) and sound (12).

The ranking inverts constantly at this level. A Medium in the exact SCSI or md path your storage appliance depends on will outrank a High in a GPU driver you do not build — and the md and block entries in particular deserve a read by anyone shipping software RAID, because storage-stack bugs tend to cost data rather than memory. The reverse holds too: a 7.8 BPF verifier entry is a serious finding on a container host and an informational note on an appliance that never loads a program.

Compliance output should say why

Severity scoring and product applicability are different questions, and a batch this size makes the cost of conflating them obvious. Every verdict your tooling emits should carry the reason and the evidence behind it — the configuration, the version range, and the runtime condition:

An SBOM consumer that cannot see why a 9.8 was dismissed will either panic or ignore you. With 878 entries in 48 hours, both failure modes arrive within the week.

How KernelScan helps

KernelScan combines kernel version, architecture and .config to decide whether vulnerable code is present in a specific build, and keeps that verdict separate from the CVE’s severity rating. Where you also select deployment security factors, those add context about the threat actors the product actually faces — which is the difference between the ksmbd example above being 16 High findings and being six pre-auth entries, eight post-auth entries and two local ones. Unresolved cases stay visible as in-triage rather than being silently closed, and the original score is never overwritten by an applicability verdict. The batch data in this post is the same corpus the product triages against, and the per-CVE cards linked above carry the full analysis for each entry.

On fixes, treat this per-CVE rather than batch-wide. The recurring stable releases across this batch are 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.51/52, 7.2.5/7.2.6 and mainline 7.3-rc1/rc2, but coverage differs by entry — the SMB Direct Critical lists 7.2.6 and mainline only because the code did not exist before 7.1, while the isofs over-read dates to 2.6.33 and is fixed on every maintained branch. Verify each applicable CVE against the branch you ship and your vendor’s backports; where a release is not listed, that is the state of the record, not proof that no backport exists.

The exposure window cuts both ways here more sharply than usual, because this batch mixes a decade-old parser bug with code that is three releases old. CVE-2026-90173 (7.1), CVE-2026-90038 (7.2) and CVE-2026-89918 (6.16) cannot be present in a 6.12 LTS build at all. CVE-2026-89778 (2.6.33), CVE-2026-90414 (3.10) and CVE-2026-89846 (2.6.36) have been there the whole time. An old introduction date marks when the flaw entered the code — not whether your patched or configuration-excluded build still carries it.