Linux Kernel CVEs: What to Patch by Device (20 – 26 Sep 2026)

This week has fewer CRITICAL records than the last two editions, which had 54 and 35. Of the 607 records, 129 carry a CNA score: 4 are CRITICAL and 125 are HIGH. The other 478 have no score. No score does not mean no risk. Most fixes are narrow. Which ones matter depends on the drivers, file systems and network services your product uses. One point needs attention this week: many records do not yet list a fix on the older longterm branches (5.10 to 6.6). The table below gives the highest fixed version on each branch. Updating to it applies every fix that exists today, but it does not close records that have no backport yet.

The one action: update to the fixed version for your branch

Find your branch in the table. If your kernel version is lower than the value in the second column, plan the update.

Every value in the table equals the newest release on that branch on kernel.org as of 26 September 2026. Branches that are not listed were not affected by this week’s records, or their fix predates this window. kernel.org lists December 2026 as the projected end of life for both 5.10 and 5.15. If you ship on either branch, plan the move to a newer longterm branch now.

Mobile and automotive

These records are in the Wi-Fi and Bluetooth stacks. A phone, head unit or telematics unit is exposed to any device in radio range, so these come first for this vertical.

CVE-2026-93806: Wi-Fi cfg80211 association response length check

The kernel read the status field and the information elements of a Wi-Fi association response before it checked that the frame was long enough. The frame comes from the access point, so a rogue access point in radio range can send a short frame. The kernel CNA scores it 8.8 with an adjacent-network vector. It applies to every device that uses the in-kernel Wi-Fi stack (CONFIG_CFG80211). Fixed in 6.12.111 and 6.18.53. The mainline fix is in 7.2, so every later release already has it. The record lists no fix yet for 5.10, 5.15, 6.1 and 6.6. See CVE-2026-93806.

CVE-2026-97442: Wi-Fi ath11k invalid data access in RX decap

The ath11k driver could receive a frame longer than the maximum native Wi-Fi header and then write past the header in ath11k_dp_rx_h_undecap_nwifi(). The kernel CNA scores it 8.8, adjacent network. It applies to Qualcomm 802.11ax chipsets driven by CONFIG_ATH11K. It is exposed to any Wi-Fi peer in radio range. Fixed in 6.12.111 and 6.18.53. The mainline fix is in 7.2, so every later release already has it. The record lists no fix yet for 5.10, 5.15, 6.1 and 6.6. See CVE-2026-97442.

CVE-2026-93790: Wi-Fi iwlwifi mvm out-of-bounds tid_data access

The Intel iwlwifi MVM driver indexed a per-TID array with a loop counter instead of the TID value in block-ack notifications. Two related records in the same driver add bounds checks on firmware notifications: CVE-2026-93793 (TX_CMD response layout) and CVE-2026-93799 (station ID in BA window status). All three are scored 8.8. They apply when CONFIG_IWLMVM is enabled. Treat the three as one update. Fixed in 6.12.111 and 6.18.53. The mainline fix is in 7.2, so every later release already has it. The record lists no fix yet for 5.10, 5.15, 6.1 and 6.6. See CVE-2026-93790.

CVE-2026-98108: Bluetooth L2CAP LE connection request channel mode

The L2CAP code could create an enhanced-credit channel in the wrong mode when it answered an LE connection request. The record says this can lead to an out-of-bounds stack write in l2cap_ecred_rsp_defer(). A peer in Bluetooth range sends the request. The kernel CNA scores it 7.5, adjacent network, high attack complexity. A related record, CVE-2026-98107, fixes an out-of-bounds write in l2cap_ecred_connect() on the local connect path and has no score. Both apply when CONFIG_BT and CONFIG_BT_LE are enabled. Fixed in 6.12.111, 6.18.53, 7.2.7 and mainline 7.3-rc2. The record lists no fix yet for 5.10, 5.15, 6.1 and 6.6. See CVE-2026-98108.

CVE-2026-93783: Bluetooth RFCOMM frame length check

The RFCOMM receive path read the frame header before it checked the frame length. A zero-length frame could make the length counter wrap and cause a large out-of-bounds read. The record has no CNA score. It is listed here because the input comes from a paired or connecting Bluetooth peer. It applies when CONFIG_BT_RFCOMM is enabled, which is common on hands-free and serial-profile devices. Fixed in 6.12.111 and 6.18.53. The mainline fix is in 7.2, so every later release already has it. The record lists no fix yet for 5.10, 5.15, 6.1 and 6.6. See CVE-2026-93783.

Embedded and IoT

These records are in drivers that are common on SoC-based boards: stateless video decoders, the I2C core, the Synopsys Ethernet MAC and the F2FS file system.

CVE-2026-97575: V4L2 stateless AV1 tile count validation

The V4L2 core did not bound the AV1 tile column and tile row counts that user space passes to stateless decoders. Decoders then used these counts as loop limits and array indexes. The fix rejects out-of-range counts in the core. Five related records in the same series add further checks: CVE-2026-97576 (HEVC tile counts in the core), CVE-2026-97577 and CVE-2026-97578 (Rockchip VPU981 AV1, CONFIG_VIDEO_HANTRO_ROCKCHIP), CVE-2026-97579 (MediaTek AV1, CONFIG_VIDEO_MEDIATEK_VCODEC) and CVE-2026-97580 (Rockchip rkvdec HEVC, CONFIG_VIDEO_ROCKCHIP_VDEC). All six are scored 7.8, local, low privilege. On a media box or camera product, any process that can open the decoder video node can reach them. Fixed in 6.12.111, 6.18.53, 7.2.7 and mainline 7.3-rc3. The record lists no fix yet for 6.6. See CVE-2026-97575.

CVE-2026-93287: I2C SMBus oversized block transfers

The SMBus core checked the block length too late. Adapters with a native smbus_xfer implementation skipped the check completely, so a user-controlled block length reached driver callbacks unchecked. The kernel CNA scores it 7.8, local. It is reachable by any process that can open a /dev/i2c-* node (CONFIG_I2C_CHARDEV). Check the permissions on those nodes on your board. Fixed in 6.12.111 and 6.18.53. The mainline fix is in 7.1, so every later release already has it. The record lists no fix yet for 5.10, 5.15, 6.1 and 6.6. See CVE-2026-93287.

CVE-2026-93830: stmmac XGMAC RX buffer unavailable interrupt storm

The XGMAC variant of the Synopsys stmmac driver enabled the RX Buffer Unavailable interrupt. Under heavy receive load this caused an interrupt storm. The record reports more than 1.8 billion interrupts against 2.6 million received packets on an Agilex5 board. The kernel CNA scores it 7.5, network, availability impact only. It applies to SoCs using the XGMAC core with CONFIG_STMMAC_ETH. A related record, CVE-2026-97953 (7.0), fixes the TX descriptor check for TSO traffic in the same driver. Fixed in 6.12.111 and 6.18.53. The mainline fix is in 7.2, so every later release already has it. The record lists no fix yet for 5.10, 5.15, 6.1 and 6.6. See CVE-2026-93830.

CVE-2026-93816: F2FS inline dentry name length check

F2FS copied file names out of an inline directory entry before it checked that each name length fits in the inline area. A corrupted image can make the kernel read past that area. The kernel CNA scores it 7.1, local, user interaction required. It applies when CONFIG_F2FS_FS is enabled and the device mounts F2FS media that an attacker can prepare, such as an SD card. Fixed in 6.12.111 and 6.18.53. The mainline fix is in 7.2, so every later release already has it. The record lists no fix yet for 5.10, 5.15, 6.1 and 6.6. See CVE-2026-93816.

Cloud and datacenter

All four CNA-CRITICAL records this week are in network storage server code. They are reachable from the network, but only on hosts that run the matching server.

CVE-2026-93207: SUNRPC RPCSEC_GSS credential decode

The NFS server RPC layer reused a per-request credential structure across requests. When decoding failed early, the structure could hold a pointer into the request’s pages together with a length left over from an earlier request. That pointer could then be used after the pages were released. The kernel CNA scores it 9.8, network, no privileges. It applies to NFS servers that accept RPCSEC_GSS (Kerberos) traffic, with CONFIG_SUNRPC_GSS and CONFIG_NFSD enabled. Fixed in 6.6.157, 6.12.109, 6.18.50, 7.2.4 and mainline 7.3-rc1. See CVE-2026-93207.

CVE-2026-93228: NFS over RDMA server zero-segment chunks

The NFS-over-RDMA server accepted Write and Reply chunks whose segment count was zero. The record describes the fix as defence in depth, because an earlier patch in the same series made the segment walk safe. The kernel CNA scores it 9.1. A related record in the same code, CVE-2026-93224 (8.1), fixes an unmatched unregister on a failed accept. Both apply to NFS servers with CONFIG_SUNRPC_XPRT_RDMA that listen on RDMA. Fixed in 6.12.111, 6.18.50, 7.2.4 and mainline 7.3-rc1. The record lists no fix yet for 5.15, 6.1 and 6.6. See CVE-2026-93228.

CVE-2026-97413: RDMA RTRS server integer underflow

The RTRS server read a user-data length from a network message and subtracted it from an offset without checking it. A client could make the result wrap to a very large value and cause out-of-bounds memory access. The kernel CNA scores it 9.8. It applies to hosts that export block devices with RNBD, using CONFIG_INFINIBAND_RTRS_SERVER. Fixed in 6.12.111 and 6.18.53. The mainline fix is in 7.2, so every later release already has it. The record lists no fix yet for 5.10, 5.15, 6.1 and 6.6. See CVE-2026-97413.

CVE-2026-100075: RDMA SRP target unwind counters

When srpt_alloc_rw_ctxs() failed partway, the SRP target driver left stale counters and a dangling pointer. Later send-queue accounting then used the wrong values. The kernel CNA scores it 9.8. It applies to SRP storage targets with CONFIG_INFINIBAND_SRPT. This is the only CRITICAL record this week with a fix on every longterm branch, including 5.10. Fixed in 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6 and mainline 7.3-rc1. See CVE-2026-100075.

CVE-2026-98115: ksmbd session drain during logoff

With SMB3 multichannel, one session can run on several connections. The in-kernel SMB server freed shared session objects on logoff without waiting for all channels. The kernel CNA scores it 8.8, network, low privilege (an authenticated client). It applies to CONFIG_SMB_SERVER. Fixed in 7.2.7 and mainline 7.3-rc2. The record lists no fix yet for 6.12 and 6.18. See CVE-2026-98115.

CVE-2026-97555: SMB client heap overflow in DACL rewrite

When the SMB client rewrote an existing DACL with owner and group SIDs from the cifs.idmap upcall, it sized the buffer from the old DACL. Longer SIDs then overflowed the allocation. The kernel CNA scores it 8.8. A second client record, CVE-2026-93787 (8.1), fixes an out-of-bounds read when an SMB1 server returns an oversized file name length in a directory listing. Both apply to hosts and devices that mount SMB shares with CONFIG_CIFS. Fixed in 6.12.111, 6.18.53, 7.2.7 and mainline 7.3-rc3. The record lists no fix yet for 5.15, 6.1 and 6.6. See CVE-2026-97555.

Medical devices

Several records above apply to network-connected medical devices. Wearables and patient monitors that use Bluetooth are exposed to CVE-2026-98108 and CVE-2026-93783. Devices on hospital Wi-Fi are exposed to CVE-2026-93806, and to CVE-2026-97442 or CVE-2026-93790 if they use those chipsets. A device that mounts an SMB share for clinical data, for example to store DICOM images or HL7/FHIR exports, is exposed to CVE-2026-97555 and CVE-2026-93787, even though it is not a server. Medical-device patching is gated by validation and regulatory revalidation (US FDA postmarket cybersecurity guidance, EU MDR, IEC 62304), so the action is to plan the stable update through the manufacturer’s change-control process.

How to check if Linux kernel CVEs apply to you

Ask three questions for each record.

1. Version. Is your kernel version lower than the table value for your branch? If yes, the fix is not in your kernel.
2. Configuration. Is the affected code built? Search the running configuration for the symbol named in the record section.
3. Reachability. Who can reach the code? Remote or over-the-air paths come first. Local unprivileged paths come next. Guest-to-host paths on shared hosts come after that. Paths that need root or a special configuration come last.

raghu@techveda.org:~$ zcat /proc/config.gz | grep -E 'CONFIG_BT=|CONFIG_BT_RFCOMM=|CONFIG_CFG80211=|CONFIG_CIFS='
CONFIG_BT=m
CONFIG_BT_RFCOMM=m
CONFIG_CFG80211=y
# CONFIG_CIFS is not set

If /proc/config.gz does not exist, check the configuration file in /boot or the build tree for the image.

Key takeaways

• 607 Linux kernel CVEs were published between 20 and 26 September 2026. 4 are CNA-CRITICAL and 125 are HIGH.
• All four CRITICAL records are in network storage server code: SUNRPC, NFS over RDMA, RTRS and SRP target.
• For radio-connected devices, the Wi-Fi (cfg80211, ath11k, iwlwifi) and Bluetooth (L2CAP, RFCOMM) records come first.
• Minimum safe versions: 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.111, 6.18.54, 7.2.8.
• Many records have no backport yet on 5.10 to 6.6. Updating applies every fix that exists; it does not close those records.
• No record notes known exploitation.

Frequently asked questions

Is there a known exploit for any of this week’s Linux kernel CVEs?
No record in this window notes known exploitation, and we found no public exploit code for the four CRITICAL records at the time of writing. All fixes are already in mainline.

Why do the CRITICAL records matter less for most embedded products?
All four are in server code for network storage: the NFS server RPC layer, NFS over RDMA, the RTRS server and the SRP target. A device that does not run one of these servers does not expose them.

I updated my 6.1 kernel to 6.1.188. Am I clear?
You have every fix that exists for 6.1 today. But at least 271 records that affect 6.1 list no 6.1 fix yet, including CRITICAL CVE-2026-93228 and CVE-2026-97413. Check whether your product enables the affected code, and watch for the next 6.1 stable release.

Why do most records have no CVSS score?
The kernel CNA scores only part of what it publishes. This week 129 of 607 records carry a score. An unscored record can still be serious, so judge it by the code it touches and how that code is reached on your product.

How is the minimum safe version calculated?
For each branch it is the highest fixed version named by any record in this window. Each value was checked against kernel.org, and each equals the newest release on that branch, so no record in this window can raise it.

Further reading

• linux-cve-announce mailing list archive
• kernel.org releases
• Linux kernel CVE process documentation
• TECH VEDA kernel CVE tracker
• Previous edition: Linux Kernel CVEs, 13 – 19 Sep 2026