Kernel CVE Batch Analysis: September 11, 2026 (431 CVEs, a file-server batch)

On September 11, 2026 the Linux kernel project published 431 CVEs in a single day — a large batch by any measure, though not the season’s peak: the same corpus shows 848 CVEs published on August 15. NVD was already partway through this one: at analysis time 278 of the 431 carried an NVD score, and the remaining 153 are KernelScan provisional assessments. The severity split is unusually top-heavy: 71 Critical, 213 High, 116 Medium, 31 Low, and 284 of the 431 rated 7.0 or higher.

The shape of the batch is worth noting. This is not a driver-of-the-week dump: 53 of the 71 Critical-rated entries fall in our NFS/RPC, SMB, Ceph and OCFS2 grouping — 52 of them in nfsd, SUNRPC, svcrdma, Ceph, SMB and OCFS2, plus one in the NLM lock server (lockd) that sits alongside them. That grouping is a starting hypothesis for triage, not a verdict: it also contains client-side code, local filesystem lifecycle bugs and on-disk metadata handling, each with its own attacker. If you ship an NFSD-exporting NAS, a Ceph-backed storage node or an SMB file server, start here. The useful question remains which of these reach the build you actually ship.

The batch at a glance

The standouts

The lead Critical of the batch is about as clean as remote kernel bugs get: CVE-2026-89659 (Critical 9.8), a use-after-free in the kernel NFS server’s delegation-revocation path. Any NFS client that holds an NFSv4 delegation and lets it time out can race the server’s laundromat against client teardown, freeing the client object while the revoke path still dereferences it. No authentication beyond being an NFS client, no local access, and the record dates the flaw to 3.10. Check the fix map for your branch: the record lists 6.18.51, 7.2.4 and mainline 7.3-rc1, with no 6.12.x entry at analysis time. If your product exports NFSv4 with delegations enabled (CONFIG_NFSD), start here — then look at its neighbours, which are not all the same bug: CVE-2026-89703 (Critical 9.8) races FREE_STATEID against the laundromat’s revoke; CVE-2026-89660 (Critical 9.8) needs a concurrent admin state revocation the attacker cannot initiate, which our provisional assessment scores lower at 8.1; and CVE-2026-89712 (Critical 9.8) sits in the NFSv4.2 inter-server-copy source-mount path rather than in client teardown.

The second standout looks identical and is not. CVE-2026-89656 (Critical 9.8) is an out-of-bounds write in the kernel Ceph client’s CRUSH-map decoder — but the attacker has to be a malicious or compromised Ceph monitor, or an on-path attacker able to inject an accepted Ceph map on an unsigned or unencrypted messenger session. That is a trusted-infrastructure threat model, not an internet-facing one: the score is real, the reachable population is “Ceph clients whose cluster-side input they do not trust,” and a sealed appliance talking only to its own cluster has a very different conversation about it. The record dates it to 4.11, so the exposure window is wide wherever Ceph is in the product.

CVE-2026-80926 completes the trio: a use-after-free in ksmbd, the in-kernel SMB server. NVD rates it 9.8 with no privileges required; our provisional assessment is 7.5 (high attack complexity, low privileges) because it needs an authenticated client holding a durable batch oplock and racing a disconnect. Products using a userspace SMB server do not carry this code path at all; anything shipping ksmbd (CONFIG_SMB_SERVER) behind client-visible SMB shares should treat it as remotely triggerable.

The high-rated CVEs, grouped by where they bite

The kernel NFS server — 54 CVEs, 21 Critical

The single biggest block of the batch, and much of it client-reachable server code: stateid and delegation lifetime bugs (CVE-2026-89659 and the revocation series), session-slot and replay races (CVE-2026-89689, Critical 9.8), async-copy teardown (CVE-2026-89675, Critical 9.8), decoder hardening against malformed compounds, and CVE-2026-89713 (Critical 9.1 by NVD; our provisional 5.6), a TOCTOU that lets a client truncate an append-only file: the size check runs on an unlocked i_size sample, so a concurrent append makes the later notify_change() apply a real truncation that the NFSD_MAY_TRUNC check would have rejected. The gate is CONFIG_NFSD; the secondary gates are which NFS versions you enable and whether delegations are in use.

SUNRPC, Kerberos and other RPC paths — 16 CVEs, 8 Critical

Most of the Criticals are a hardening series against short and oversized tokens in the krb5 MIC and wrap/unwrap paths: CVE-2026-89537 (Critical 9.1), CVE-2026-89542 (Critical 9.8), CVE-2026-89550 (Critical 9.8) and five more. They sit in the RPCSEC_GSS paths, so a target that never offers sec=krb5 does not process the tokens — but the attacker side is cheaper than that suggests: our assessments for 89542 and 89551 are PR:N because the token is parsed before authentication completes, so no valid Kerberos identity is needed, only the ability to send RPC traffic to a host that accepts RPCSEC_GSS. The group is not only Kerberos: CVE-2026-89536 is an NFS client RPC-with-TLS (RFC 9289) handshake race, and CVE-2026-89546 is an NFS callback/backchannel teardown race our assessment reads as local (7.0). Fix clock varies inside the group: the MIC fix (89537) is listed for 7.2.4 and mainline only at analysis time, while siblings such as 89542 and 89550 do have 6.12.109 entries.

RPC-over-RDMA (svcrdma) — 10 CVEs, 4 Critical

Chunk-list and inline-reply validation in the RDMA transport for NFS: oversized Read segments, unvalidated chunk positions, reply pull-up overflows (CVE-2026-89526, Critical 9.8). Reachable by RDMA-capable NFS clients against an RDMA-enabled server, with no authentication required at the transport layer. Gate: CONFIG_SUNRPC_XPRT_RDMA. A concrete filter: NFS over TCP is unaffected even where CONFIG_NFSD is on.

Ceph client — 12 CVEs, 8 Critical

Besides the CRUSH-map overflow above, a systematic pass over unbounded decodes in the MDS-map, session, xattr and capability paths: CVE-2026-89651 (Critical 9.8), CVE-2026-89650 (Critical 9.1), CVE-2026-89655 (Critical 9.8). The eight Criticals are driven by malicious or compromised monitor maps or MDS replies, or by an on-path attacker on an unsigned or unencrypted session; the local xattr-disclosure path (89649) is triggered by an ordinary local read of a file whose xattr blob came from the cluster. A separate High, CVE-2026-89657, is driven by a malformed authenticated OSD reply rather than by monitor or MDS input. The group is not uniform: 89655 is our provisional AV:L/PR:L 7.0, because ordinary file I/O by a local user on a mounted CephFS triggers the cap-flush race, and CVE-2026-89646 is a local writeback-abort inode-reference leak at unmount with no peer actor at all. What does hold across all twelve is that they are not reachable by arbitrary internet peers. Gates: CONFIG_CEPH_FS, CONFIG_CEPH_LIB, CONFIG_BLK_DEV_RBD.

SMB, both directions — 14 CVEs, 8 Critical

Server side (ksmbd): the oplock-break use-after-free above plus CVE-2026-89635 (Critical 9.8), a durable-handle reconnect rebinding every detached oplock to the reconnecting session. Client side (12 entries across the smb: and cifs: subjects): CVE-2026-89637 (Critical 9.8) frees a response buffer on a malformed TRANSACT2 secondary, CVE-2026-89636 (Critical 9.8) leaves a DFS-cache target hint dangling — both reachable against a malicious or compromised server or an on-path attacker. The client family is not only malformed-reply handling: CVE-2026-89638 is a local setuid/setgid persistence issue. Gates: CONFIG_SMB_SERVER (ksmbd), CONFIG_CIFS (client).

OCFS2 and its cluster DLM — 7 CVEs, 3 Critical

A hardening series that splits three ways. CVE-2026-89494 (Critical 9.8) and CVE-2026-89495 (Critical 9.8) trust peer-supplied lock-migration fields in the o2dlm, reachable from a node inside the cluster domain. CVE-2026-89492 (Critical 9.8) is an on-disk directory-index validator — crafted metadata plus the ability to mount it, not a cluster message. The rest (heartbeat, refcount, readdir, CoW) are lower-severity correctness and leak fixes. Our product analysis reports the gate symbols per affected path: the two DLM entries map to CONFIG_OCFS2_FS_O2CB, while the file-format and heartbeat entries map to CONFIG_OCFS2_FS.

NTFS and untrusted images — 5 Criticals (new driver), plus 3 ntfs3 Highs

CVE-2026-89613 (Critical 9.8), CVE-2026-89612 (Critical 9.8) and CVE-2026-89610 (Critical 9.8) parse attacker-supplied NTFS metadata into memory corruption and are scored Critical by NVD. Our provisional assessments are lower (mostly local, privileged mount), because mounting requires privileges in the init namespace or an automount path plus removable media — kiosks, desktops, forensics gear. The version story is a split, not a rule: three of the five are new code introduced in 7.1, but 89610 and 89611 date back to 2.6.12, and all five list fixes only in 7.2.4 and 7.3-rc1. Do not read that as “old kernels are safe” or “old kernels are doomed” — check your driver, branch and vendor backports. Gates: CONFIG_NTFS_FS and, for the separate driver’s three Highs (89615/89616/89617), CONFIG_NTFS3_FS.

Transports and network paths

SCTP got two peer-reachable use-after-frees in chunk processing (CVE-2026-89479, Critical 9.8; CVE-2026-89478, Critical 9.8) — one bundled-packet lifetime bug recorded since 2.6.12. SMC-R (Shared Memory Communications over RDMA) got a peer-driven out-of-bounds read in LLC link negotiation (CVE-2026-80986, Critical 9.8). MPLS multipath (CVE-2026-89555, Critical 9.8) and SRv6 decap (CVE-2026-80976, Critical 9.8 — our provisional read: local unprivileged via netns, 7.1) round out the list, plus CVE-2026-81002 (Critical 9.8), an AF_XDP zero-copy frame-layout overflow our assessment gates behind CAP_NET_ADMIN.

Local kernel core

Three entries, and they do not share a privilege level. CVE-2026-89762 (High 7.8) is an AppArmor credential-lifetime fix requiring the ability to update AppArmor profiles. CVE-2026-89771 (High 7.8) is a ring-buffer sub-buffer resize race; our provisional 6.2 puts it at PR:H, because using the tracing interface needs root or CAP_SYS_ADMIN. CVE-2026-89581 (High 7.8; our provisional 8.5 with scope change) is an x86 BPF JIT code-generation bug, reachable by a local actor who can load BPF programs — on a container host or multi-tenant box that is an escalation path rather than noise. On a sealed single-tenant appliance that loads no BPF programs, the exposure is correspondingly smaller; that is a property of the deployment, not of the product label “appliance.”

The one that corrupts data instead of memory

CVE-2026-89558 (Critical 9.8 by NVD; our provisional 5.1) is an inverted boolean in RAID10 recovery: when a device is recovered while another mirror is still missing and the array is written to during that degraded window, an internal-bitmap array can clear bitmap bits the still-missing device needs, so the later re-add marks the disk in-sync while it holds stale data — silent on-disk corruption, with recovery completing in milliseconds because the affected regions are skipped. The array can still be caught by an explicit md check, which reports mismatch_cnt. It needs an administrator managing disks rather than an attacker, and it can equally arise during ordinary recovery without malicious activity. Storage appliances on 6.12+ with RAID10 and internal bitmaps: check resync behaviour after degraded writes. Introduced in 6.12; fixes listed for 6.12.109, 6.18.50 and 7.2.4.

Appliance triage

A useful example: seven CVEs, one config symbol, two attacker classes

Take the OCFS2 cluster. All seven of its CVEs — two Criticals in the DLM wire handlers, one on-disk validator, the heartbeat and remaining fixes — drop out of scope once the corresponding OCFS2 symbols are unset, which is the case for every product that is not deliberately building an OCFS2 cluster. That is the first filter, and it removes seven entries, three of them Critical, in one line of the config audit.

The second split is attacker class. NVD scores CVE-2026-89494 at 9.8 network-vector; our provisional assessment is 8.0 with adjacent-network access and low privileges, because the malformed migration message has to come from a node inside the DLM domain. So the honest VEX statement splits OCFS2 products in two: a clustered OCFS2 deployment is affected through its peer nodes and should patch; a product whose kernel does not include the code gets a not-affected verdict with a code-not-present justification — not because the code is unreachable in principle, but because it is absent from that build. Same CVE id, two correct answers, and the difference is one Kconfig symbol and one question about who your product’s peers are. Note that both verdicts keep the NVD rating attached: applicability and severity are recorded separately.

Medium and low still matter

The 116 Mediums are where product-specific judgment lives. Many sit in drivers — including a power-supply and HID series spanning suspend, teardown and device-response handling, so hot-unplug is only one of the relevant conditions — with the rest across network paths, filesystems and platform code. A Medium in the exact subsystem your appliance ships will outrank a generic High in code you never load; the efivarfs, zram and hp-bioscfg entries in this batch are good examples of fixes that are boring in a CVSS sort and urgent in a product sort. We do not publish a precise driver/non-driver split here, because the obvious subject-line grouping is not reliable enough to justify one.

Compliance output should say why

Every CVE your tooling emits a verdict for should carry its reason, and severity scoring is a different question from product applicability. A CVE can carry no NVD score while its applicability to your build is already resolved in one direction or the other: our own product output marks an unscored io_uring entry (CVE-2026-81009, scored only by our assessment) as exploitable where CONFIG_IO_URING is enabled, and marks scored CVEs not-affected where the mapped code is absent. Record the configuration, version range and runtime conditions behind each verdict:

An SBOM consumer that cannot see why a 9.8 was dismissed will either panic or ignore you; both are expensive.

How KernelScan helps

KernelScan combines kernel version, architecture and .config with available CVE mappings 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 your product actually faces — so an entry can be not-affected because NFS is not part of the deployment, or exploitable because untrusted local code runs and BPF is reachable. Unresolved cases stay visible as in-triage rather than being silently resolved, 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 as per-CVE rather than batch-wide: for the entries checked, the records list fixes in 6.12.109, 6.18.50/51, 7.2.4/7.2.5 and mainline 7.3-rc1/rc2, but coverage differs by CVE — the lead nfsd CVE has no 6.12.x entry at analysis time, the MIC fix lists 7.2.4 and mainline only, and several others are 7.2-only. 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: nine of the entries named above are recent code — CVE-2026-89635 (7.2), CVE-2026-89546 (6.19), CVE-2026-89689 and CVE-2026-80986 (6.14), CVE-2026-89651 and CVE-2026-89581 (6.10), CVE-2026-89660 (6.9), CVE-2026-89771 (6.8) — so a product on 6.12 LTS cannot contain the later four. An old introduction date is not automatic current exposure either: it marks when the flaw entered the code, not whether your patched or configuration-excluded build still carries it.