Kernel CVE Batch Analysis: October 6-7, 2026 (210 CVEs, 39 in Wi-Fi)

On October 6, 2026 the Linux kernel project published 208 CVEs in a single day, followed by two stragglers on October 7. That makes 210 entries — a smaller wave than the 606 of September 24–25, but with three Criticals and 92 entries rated 7.0 or higher.

The top of the CVSS list belongs to RDMA storage fabrics and the SMB client. Most embedded products never build RDMA, and many don’t mount shares. What they do build is Wi-Fi — and 39 entries in this batch are in Wi-Fi, from the stack every Linux device shares to the chips found in industrial and IoT hardware. So this post starts there, and covers the rest of the batch after it.

As always, the useful question is not how many there are. It is which of them reach the product you ship.

Wi-Fi in focus: 39 CVEs, sorted by where the attacker stands

Industrial gateways, cameras, HMIs, set-top boxes, medical devices and consumer IoT all carry a radio. This batch has 39 Wi-Fi entries — 17 High, 16 Medium, 6 Low — across the shared stack and a dozen drivers.

For a radio, what matters is not “how high is the score” but where does the attacker have to be, and what does the device have to be doing. Sorted that way, the 39 fall into six groups.

Shared stack or chip driver?

Before the attacker, the code. 20 of the 39 sit in the shared Wi-Fi stack, not in a chip driver — 7 in cfg80211, 13 in mac80211. That split decides whether your hardware choice protects you:

• cfg80211 is the configuration layer every Linux Wi-Fi driver uses. If your device has Wi-Fi on Linux, it has this code. No chip choice opts you out.
• mac80211 is only used by “soft-MAC” chips, where the kernel builds the 802.11 frames itself — Qualcomm Atheros, MediaTek, Intel iwlwifi, Realtek. “Full-MAC” chips that run the protocol in firmware, such as Broadcom/Infineon brcmfmac, Marvell mwifiex and Microchip wilc1000, don’t touch it.
• The individual drivers — the other 19 entries, spread over a dozen drivers — only matter if you ship that silicon. Notably, brcmfmac, the driver behind Raspberry Pi-class boards and many Infineon modules, appears exactly once, at Low 2.5.

Group 1: anyone in range, before you connect

These are the ones that should worry an embedded team. A Wi-Fi client learns about networks by listening to beacons and probe responses — unauthenticated frames that anyone can transmit. The kernel parses them during every scan, before any password is involved. A device that is not connected to anything but has its radio on is still parsing them.

• CVE-2026-98185 (High 8.7) — Marvell mwifiex trusts lengths in the scan result its firmware hands back. A crafted beacon can make the firmware report a malformed result, and the kernel parser walks past the buffer. Present since 3.0.
• CVE-2026-98186 (High 8.1) — also mwifiex: a beacon’s security element claims up to 255 cipher suites, and the driver reads that many without checking the element’s length — up to a kilobyte past it.
• CVE-2026-98340 (Medium 6.4, our score) — in cfg80211, so every Linux Wi-Fi client. A sequence of probe responses and hidden-SSID beacons for one BSSID corrupts how the kernel groups scan results. The result is a kernel warning; on a system with panic_on_warn set, a reboot.
• CVE-2026-98349 (High 7.1) — a 24-byte beacon makes the old Intel ipw2x00 library compute a 64 KiB element length. Hardware from the mid-2000s; relevant only if you still ship it.
• CVE-2026-98191 (Low 3.1) — TI wlcore (WL18xx modules) leaks a power-management reference when a regulatory-domain update fails. Nobody gets code execution; the radio just stops sleeping, which matters on a battery.

mwifiex drives Marvell/NXP 88W8xxx chips, found on many i.MX-based boards and industrial modules. One caveat before you mark yourself affected: many NXP BSPs ship NXP’s own out-of-tree driver instead of the upstream mwifiex. Check which module your image actually loads — that answers this pair, not the chip’s part number.

Group 2: posing as your access point

• CVE-2026-98339 (High 8.8 by the CNA, ours 6.5) — again cfg80211, again every Linux client. The attacker sends beacons that copy your access point’s identity on another channel, then announces a channel switch. The kernel’s table of known networks ends up inconsistent. Beacons are not authenticated on most networks, so impersonating the AP for this purpose needs no key. The CNA rates the impact as full compromise; we read it as a crash. Either way, it is the most broadly reachable bug in the batch for embedded products.
• CVE-2026-98348 (High 7.1) — a short association response makes the ipw2x00 parser read up to 64 KiB past the receive buffer. Same legacy hardware as above.

Group 3: only in special modes

• CVE-2026-98190 (High 8.0, our score) — Microchip wilc1000, a common IoT module. A Wi-Fi Direct (P2P) action frame of 25–31 bytes makes the driver scan up to 4 GiB past the frame and crash. Only reachable while the device is in P2P listen state. Many products use P2P for out-of-box provisioning: the device is exposed during setup and safe afterwards. If yours keeps P2P on, that changes.
• CVE-2026-98193 (High 8.1, our score) — a short TKIP frame makes ipw2x00 read past the buffer. TKIP is WPA1-era encryption; if your device never negotiates it, this is unreachable.

Group 4: the module itself is the attacker

Three entries trust data the Wi-Fi hardware reports: a wilc1000 transfer size on SDIO (CVE-2026-98189, Medium 6.4, up to 32 KiB written past the buffer) and two calibration-table parsers in the Prism54 p54 USB driver. They need a malicious or tampered module. For a sealed product with a soldered-down chip, that is a supply-chain question. For a device with an open USB port and p54 built in, anyone with physical access can plug one in.

Group 5: local code that can configure the radio

The largest group, and on most embedded products the least urgent. These 23 entries are reached through nl80211, the netlink interface that wpa_supplicant, hostapd and NetworkManager use, and almost all need CAP_NET_ADMIN. The highest are a heap overflow in mwifiex authentication (CVE-2026-98184, High 7.8, where about 64 KiB of caller data lands in a buffer sized for six bytes), a scan-request use-after-free (CVE-2026-98341, High 7.8) and a TDLS operation that can target the access point’s station entry (CVE-2026-98332, High 7.7).

Who can actually issue these calls decides the risk:

• Unprivileged user namespaces on — any local user gets CAP_NET_ADMIN in their own namespace. On a multi-user Linux system with Wi-Fi, these are real privilege-escalation paths.
• Sealed device, user namespaces off — only root and the Wi-Fi daemons can reach them. The attacker would already need to control wpa_supplicant or the provisioning service. Then the question is how well that daemon is isolated, not this CVE.
• Mesh — three of the 23 only exist with CONFIG_MAC80211_MESH. Most products don’t need 802.11s mesh; turning it off removes them.

Group 6: teardown races

Four use-after-frees fire when a device is removed or radio-killed while a timer is running — brcmsmac, libertas_tf, wcn36xx and the Intel 4965 driver. Real bugs, hard to trigger on purpose. Patch them with the rest.

What this means for a product with Wi-Fi

The whole batch at a glance

The standouts

Two Criticals for the data center

CVE-2026-98365 (Critical 9.8) and CVE-2026-98323 (Critical 9.8) are in software RDMA: Soft-RoCE (rxe) and software iWARP (siw), which turn an ordinary Ethernet port into an RDMA device. Both are remote and unauthenticated, and the kernel CNA and we agree exactly on both.

They are also easy to rule out. CONFIG_RDMA_RXE and CONFIG_RDMA_SIW are off by default and rarely built outside general-purpose server kernels. Even where the modules are present, nothing listens until an admin binds them to an interface (rdma link add … type rxe netdev eth0). Not built: code not present. Built but unbound: code not reachable — name the condition.

The SMB client Critical, again

CVE-2026-98167 (Critical 9.1, our score) and CVE-2026-98171 (High 8.8 by the kernel CNA, ours 9.8) are two bugs in the same code: how the SMB client takes apart an encrypted compound reply. The first reads past the buffer, the second uses freed memory.

As in the last batch, the attacker is the file server you mount, not a client connecting to you. With CONFIG_CIFS=n both are gone. With it built, the real question is which servers your product talks to, and whether a user can point it at a new one.

The one you can’t configure away

CVE-2026-98255 (High 8.1, our score) is in the TCP receive fast path. A segment carrying a very old ACK number could have its payload delivered before the ACK check rejected it. The segment still needs the exact next expected sequence number, so this is an on-path or sequence-guessing attack, not a one-packet exploit.

But there is no CONFIG_* to turn off. Every product with a TCP stack has this code. It is fixed in every maintained branch back to 5.10.271, and for an internet-facing device that fix is the only filter.

Score comparison: kernel CNA vs. KernelScan

The kernel CNA published its own CVSS score for 52 entries in this batch, all of them 7.0 or higher. We score every CVE independently, so these 52 give a direct comparison.

Same number, different reasoning

The totals are close. The vectors behind them often are not. Two metrics explain most of the gap.

Attack complexity, 23 times. In 21 of them the CNA scores a race condition as low complexity and we score it high: the attacker has to win a timing window. That one metric is why so many 7.8s become 6.9s. Neither reading is wrong — races do get won in practice — but it is the single biggest systematic difference.

Attack vector, 8 times. This is the one that matters for products, because it changes who the attacker is:

• 4 we read as network, the CNA as local. Two IPsec receive-path bugs (CVE-2026-98369 and CVE-2026-98229, both High 7.8), an IPv6 IPsec error-path bug (CVE-2026-98241, High 7.8) and an Open vSwitch conntrack race (CVE-2026-98251, High 7.8). The trigger is a packet from the network. On a VPN gateway or a virtual switch, that is the more useful reading.
• 2 the CNA reads as network, we as adjacent. The iSER target (CVE-2026-98357, High 8.1) and RDS over InfiniBand (CVE-2026-98257, High 7.5). The attacker has to be on the RDMA fabric, which is usually a dedicated storage network.
• 1 the CNA reads as adjacent, we as local. CVE-2026-98290 (High 7.5 by the CNA, ours 4.7), an RFCOMM deadlock. The CNA shows a Bluetooth peer can drive both halves of the race. Its reading is the better one here.
• 1 the CNA reads as network, we as local. CVE-2026-98173 (High 7.5), an SMB multichannel race that a local user on the client sets off.

The biggest gaps

• CVE-2026-98339 (High 8.8 by the CNA, ours 6.5) — a rogue Wi-Fi access point corrupts the client’s scan table during a channel switch. We agree on radio range; we read the impact as a crash, not a takeover.
• CVE-2026-98283 (High 8.8 by the CNA, ours 7.0) — a nested-virtualization race on POWER KVM hosts. Guest-to-host, so the higher number is defensible on a POWER hypervisor. Everyone else can skip it.
• CVE-2026-98169 (High 7.1 by the CNA, ours 5.3) — the SMB server can make the client leak up to 12 bytes of kernel heap to a local process.
• CVE-2026-98216 (High 7.1 by the CNA, ours 5.4) — an Omni-Path driver bug behind a device file.
• CVE-2026-98171 (High 8.8 by the CNA, ours 9.8) — the one large gap in the other direction, in the SMB client (above).

The published score stays the CNA’s. The comparison is a reminder that a CVSS number compresses a threat model into one digit — and for product triage, the vector is the part worth reading.

The high-rated CVEs, grouped by where they bite

Network-reachable: 18 Highs

RDMA and RDS — 6 Highs, 2 Critical. The two software-RDMA Criticals, the iSER target and initiator (CVE-2026-98357, High 8.1; CVE-2026-98358, High 7.5), and two RDS bugs. One of those, CVE-2026-98271 (High 8.9, our score), is RDS over plain TCP — only reachable with CONFIG_RDS_TCP loaded and in use.

SMB client — 7 Highs, 1 Critical. Four of them come from the server, three from races on the client during reconnect. Covered above.

Core networking — 3 Highs. The TCP fast-path bug, a ring-slot leak in packet sockets (CVE-2026-98233, High 7.5) that can blind a packet-capture or monitoring tool, and an IP-TFS reassembly overflow (CVE-2026-98371, High 8.7). IP-TFS arrived in 6.14 and needs CONFIG_XFRM_IPTFS plus a tunnel that uses it.

NIC drivers — 2 Highs. Microchip lan743x (CVE-2026-98239, High 8.1) and the Cortina Gemini Ethernet in old StorLink NAS chips (CVE-2026-98275, High 7.5). If you don’t ship the silicon, you don’t ship the driver.

Radio range: 12 Highs

• 8 Wi-Fi — covered in the Wi-Fi section above.
• 4 Bluetooth — led by CVE-2026-98291 (High 8.8), an off-by-one write in Intel’s PCIe Bluetooth driver. Introduced in 6.10.

A product with no radio drops all twelve.

Local: 62 Highs

IPsec — 8 Highs. Use-after-free bugs in state handling, bundle creation and the receive path. Several need CAP_NET_ADMIN, which unprivileged user namespaces hand to any user. Two are worth a closer look on VPN gateways: CVE-2026-98369 and CVE-2026-98229 (both High 7.8) can be triggered by IPsec traffic from a peer, even though the CNA scored them local.

Core kernel and memory — 9 Highs. No config switch for most of these: futex after vfork() (CVE-2026-98281), a UDP socket race (CVE-2026-98276), three POSIX CPU timer and signal races, an encrypted-keys overflow (CVE-2026-98222), and CVE-2026-98373 (High 7.8), a hugetlb mremap page-table corruption from October 7. On a multi-user or container host, these are the queue.

Architecture-specific — 4 Highs. Two POWER KVM guest-to-host bugs, an arm64 percpu atomics bug on CPUs with LSE (CVE-2026-98248), and missing barriers on Mobileye EyeQ MIPS cores. Your architecture answers these before your config does.

RDMA local — 8 Highs. All need access to an RDMA device node. One stands out on servers: CVE-2026-98361 (High 7.8) lets a user have Soft-RoCE traffic overwrite the page cache of a read-only file, such as a setuid binary — the same primitive as Dirty Pipe. Introduced in 6.16.

Drivers — the rest. DMA engines on Marvell PXA/MMP SoCs, dma-buf, stmmac, mvpp2, AHCI quirks and GPU memory management. Mostly hardware-gated.

Appliance triage

Medium and low still matter

118 entries score below 7.0. 55 are in drivers, led by networking (14) and GPU (12), then RDMA, MMC and input (6–7 each). The rest sit in networking (35), filesystems (9) and sound (7).

Some sit just under the line. CVE-2026-98374 (Medium 6.9, our score), the second October 7 entry, is a TCP retransmit-queue use-after-free that an unprivileged process can arm with TCP Fast Open and a crafted ICMP message. On a multi-tenant host that is not a Medium-priority problem. On a sealed appliance with no local users, it is.

Compliance output should say why

Severity and applicability are different questions. Every verdict should carry its reason:

How KernelScan helps

KernelScan checks kernel version, architecture and .config to decide whether the vulnerable code is in your build at all. That verdict stays separate from the CVE’s severity score, which is never overwritten — whatever its source.

The security factors you select add the threat model: whether there are local users, whether the device has radios, whether it talks to servers it doesn’t control. That is what turns the 39 Wi-Fi entries above into a short list for your chip, your driver and your modes — instead of 17 High findings.

Which fixes to take

This batch is unusually well backported. The recurring releases are 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.54, 7.2.8 and 7.3-rc4. The two October 7 entries need one release more on the newest branches: 6.18.55, 7.2.9 and 7.3-rc5.

Of 140 entries whose flaw predates 6.6, 99 already list a 6.6 fix and 120 a 6.12 fix. Older branches are thinner: 86 for 6.1, 67 for 5.15, 58 for 5.10. If you ship one of those, a missing branch still means “check your vendor’s tree”, not “you’re covered”.