Linux Kernel CVEs: What to Patch by Device (13 – 19 Sep 2026)

878 records in one week is roughly double the previous week, which had 443. But volume and severity are not the same thing. This week has fewer CRITICAL records than last week did, 35 against 54. What changed is the spread. Last week the CRITICAL records sat almost entirely in network filesystem and remote procedure call code. This week they are spread across many subsystems, so more product types are touched by at least one of them.

Most of these fixes are narrow. Which of these Linux kernel CVEs matter to you depends on what your product builds and how it is configured. A phone, a factory gateway, a storage server and a patient monitor compile different code, so they are exposed to different parts of this list. The kernel CNA scores only some records. This week 319 of the 878 records carry a score and 559 do not. An unscored record is not a safe record. It only means no score was assigned. So order your work by reachability and by what your product actually runs, not by score alone.

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

Check the kernel version you are running:

raghu@techveda.org:~$ uname -r
6.12.104

Compare that to the table below. If your version is lower than the value for your branch, plan the update. If it is equal or higher, this week’s records are already covered on that branch.

Each value above is the highest fixed patch level that appears anywhere in this week’s 878 records for that branch. Each one also equals the newest release on that branch as of 19 September 2026, so the table is a ceiling and not an estimate. Branches that are not listed were either not affected by this set or their fix landed before this window.

One branch needs a decision rather than an update. The 7.1 branch reached end of life with 7.1.13 on 2 September 2026. No record in this week’s set names a 7.1 fixed version, because nothing is being backported there any more. If a product is on 7.1, the work item is a move to 7.2, not a patch.

Mobile and automotive

These records matter most where a device has a radio that strangers can reach, or where a hypervisor runs guests.

CVE-2026-89774: Bluetooth SCO use-after-free

Score 8.8. The fix is “Bluetooth: SCO: hold sk properly in sco_conn_ready“. A socket pointer is read without holding the connection lock and without holding a reference, so a connection arriving at the same time as a socket close can touch memory that has been freed. The attack vector is adjacent network, meaning someone within Bluetooth range rather than someone on the internet. That is the normal situation for a car head unit, a handset or a wearable in a public place. The gate is CONFIG_BT with SCO support, which is what carries voice calls and headset audio. See CVE-2026-89774.

CVE-2026-89775: KVM on arm64 mishandles negative stage-1 walk levels

Score 9.3. The fix is “KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation”. It is reached from inside a guest on an arm64 host that runs nested virtualisation. This is relevant to automotive designs that consolidate several domains onto one SoC behind a hypervisor. The gate is CONFIG_KVM on arm64 together with nested virtualisation actually being used. A board that runs no guests is not exposed. See CVE-2026-89775.

CVE-2026-89914: KVM on arm64 sign-extends the address for range TLB invalidation

Score 9.3. The fix is “KVM: arm64: Sign-extend VA for range-based TLBI invalidation”. Same family and same gate as the record above. Three more arm64 KVM records in this week’s set carry the same 9.3 score: CVE-2026-89915, CVE-2026-89916 and CVE-2026-89918. If you run nested guests on arm64, treat the five together as one update rather than picking through them. See CVE-2026-89914.

CVE-2026-90049: network core mishandles the source buffer in skb_zerocopy()

Score 9.3. The fix is “net: skbuff: don’t skb_tx_error() the source skb in skb_zerocopy()“. This sits in core socket buffer handling, so it is not tied to one driver or one protocol. Any device that forwards or tunnels traffic runs this path. There is no special config gate to check beyond networking being enabled, which it always is. See CVE-2026-90049.

Embedded and IoT

For embedded products the exposure usually comes from two places: filesystem code that parses media the device did not create, and the IPsec stack on devices that build a VPN back to a fleet server.

CVE-2026-89778: ISO9660 out-of-bounds read on an empty compressed block

Score 9.8. The fix is “isofs: fix out-of-bounds page array access on empty zisofs block”. It is reached by reading a crafted ISO image. This matters for kiosks, medical carts, industrial PCs and any device that will mount a disc or an ISO file handed to it by a user. The gate is CONFIG_ISO9660_FS together with CONFIG_ZISOFS. Many embedded builds leave ISO9660 enabled without ever needing it, so this is a good record to check your config against. See CVE-2026-89778.

CVE-2026-90048: NTFS3 out-of-bounds write when building an attribute list

Score 9.8. The fix is “fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list()“. A fixed-size buffer is allocated and then written past. It is reached by mounting or writing to a crafted NTFS volume, which on an embedded device usually means a USB stick someone plugged in. The gate is CONFIG_NTFS3_FS. See CVE-2026-90048.

CVE-2026-89779: NTFS3 does not validate an extended attribute record size

Score 9.1. The fix is “fs/ntfs3: validate ef->size covers the record’s name and value”. Same gate and same reachability as the record above, so the same USB stick reaches both. See CVE-2026-89779.

CVE-2026-89783: IPv6 IPsec out-of-bounds write when the security path is full

Score 9.8. The fix is “xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full”. The depth check happens too late, so a packet can write past the end of the security path array. This is reached by a packet arriving on an IPsec-enabled interface. Many fleet devices build an IPsec tunnel home, which makes this remotely reachable in normal operation. The gate is CONFIG_XFRM with IPv6 enabled. See CVE-2026-89783.

CVE-2026-92489: IPsec double free on the direct output path

Score 9.8. The fix is “xfrm: Fix skb double-free in xfrm_dev_direct_output()“. A return value other than 1 from local_out() is handled wrongly and the buffer is freed twice. The gate is CONFIG_XFRM, and the direct output path applies where IPsec offload to the network device is in use. Note the CVE number: this week’s IDs are not one continuous run, and this record sits in a later block than the others around it. See CVE-2026-92489.

CVE-2026-90012: SPI leaves DMA mappings owned wrongly after a partial failure

Score 9.8. The fix is “spi: Fix DMA mapping ownership on partial map failure”. If the receive mapping fails after the transmit mapping already succeeded, ownership of the buffers is left inconsistent. SPI is everywhere in embedded designs, connecting flash, sensors, displays and radios. The gate is CONFIG_SPI with a controller that uses DMA. See CVE-2026-90012.

Cloud and datacenter

This is where the bulk of this week’s CRITICAL records land. The pattern is consistent: a service parses a protocol message from a peer before that peer has proved who it is.

CVE-2026-89969: NVMe over TCP target out-of-bounds write on an over-long PDU

Score 9.8. The fix is “nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU”. nvmet_tcp_try_recv_pdu() reads a PDU header and does not bound it correctly. This is an unauthenticated network path into a storage target. If you export block storage over NVMe/TCP, treat this as the first item on the list. The gate is CONFIG_NVME_TARGET_TCP. See CVE-2026-89969.

CVE-2026-90230: NVMe target heap out-of-bounds read during authentication

Score 9.1. The fix is “nvmet: fix heap out-of-bounds read in nvmet_auth_negotiate()“. It is reached during authentication negotiation, which means before authentication has completed. The gate is NVMe target authentication support, CONFIG_NVME_TARGET_AUTH. A related record, CVE-2026-89970 at 9.8, fixes the NVMe target authentication code as well, and CVE-2026-89972 at 9.8 is in the NVMe host core. See CVE-2026-90230.

CVE-2026-89788: ksmbd tree connection use-after-free

Score 9.8. The fix is “ksmbd: fix tree connection use-after-free in smb2_tree_connect()“. The connection is published before it is fully set up, so another thread can use it while it is being torn down. ksmbd is the in-kernel SMB server, so this is reachable by anything that can open an SMB session. The gate is CONFIG_SMB_SERVER. If you do not export SMB shares from the kernel server, you are not exposed to this one. See CVE-2026-89788.

CVE-2026-90173: SMB Direct frees completion queues incorrectly

Score 9.8. The fix is “smb: smbdirect: free completion queues with ib_free_cq()“. SMB Direct is SMB carried over RDMA, used for high-throughput file serving. You are exposed only if SMB Direct is built and enabled, which is a deliberate choice rather than a default. On the client side that option is CONFIG_CIFS_SMB_DIRECT; on the ksmbd side it is the server’s RDMA option. See CVE-2026-90173.

CVE-2026-90036: NFS server use-after-free while reaping blocked locks

Score 9.8. The fix is “NFSD: Prevent client use-after-free during blocked-lock reaping”. A lock owner whose last reference is dropped during reaping can leave the client structure referenced after it is freed. Two sibling records in the same file, CVE-2026-90037 and CVE-2026-90038, also score 9.8. The gate is CONFIG_NFSD. Any host exporting NFS runs this code. See CVE-2026-90036.

CVE-2026-90104: NFS client does not zero referring call lists before decoding

Score 9.8. The fix is “NFSv4.1: zero referring call lists before decoding”. decode_cb_sequence_args() allocates a structure and decodes into it without clearing it first. This one is on the client side and is reached through the NFSv4.1 callback channel, which the server calls back into. That means a machine that only mounts an NFS share is in scope, not just a server. The gate is CONFIG_NFS_FS with NFSv4.1. A second client record, CVE-2026-90151 at 9.8, is in fs/nfs/client.c. See CVE-2026-90104.

CVE-2026-89990: Ceph client takes a session pointer without the mutex

Score 9.8. The fix is “ceph: lock mutex in ceph_mds_check_access()“. Handling of an MDS session OPEN message replaces a structure that another path reads without holding the mutex. It is reached by a machine that mounts CephFS. A second Ceph record, CVE-2026-90042 at 9.8, is in the client’s crypto code. The gate is CONFIG_CEPH_FS. See CVE-2026-89990.

CVE-2026-90235: SUNRPC socket callbacks read and written without annotation

Score 9.8. The fix is “sunrpc: xprtsock: annotate shared socket callbacks with READ_ONCE/WRITE_ONCE”. The transport replaces and restores socket callbacks that another CPU may be reading at the same time. SUNRPC underpins both NFS and other RPC users, so this is broad: the gate is CONFIG_SUNRPC, which is pulled in by NFS on either side. See CVE-2026-90235.

CVE-2026-90413: iSER accepts a login PDU claiming more data than arrived

Score 9.1. The fix is “IB/isert: reject login PDUs declaring more data than was received”. This is the iSCSI Extensions for RDMA target, reached during login, so before authentication. A sibling record CVE-2026-90414 at 9.1 is in the same file. The gate is CONFIG_INFINIBAND_ISERT. See CVE-2026-90413.

CVE-2026-89857: qla2xxx sends an NVMe LS reject without holding the queue-pair lock

Score 9.8. The fix is “scsi: qla2xxx: Hold qpair lock when sending NVMe LS reject”. This is the QLogic Fibre Channel driver on the NVMe-over-FC path. Two other qla2xxx records this week score in the same band: CVE-2026-89847 at 9.8 and CVE-2026-89846 at 9.1. The gate is CONFIG_SCSI_QLA_FC and the presence of QLogic FC hardware. See CVE-2026-89857.

CVE-2026-89930: KVM nested VMX service handling

Score 9.3. This is the x86 counterpart to the arm64 KVM records above, in arch/x86/kvm/vmx/nested.c. It is reached from inside a guest on an Intel host running nested virtualisation. The gate is CONFIG_KVM_INTEL with nesting enabled. On a shared host this is the record that crosses a tenant boundary. See CVE-2026-89930.

Medical devices

Connected clinical equipment is touched by this week’s set in three ways, all through records already described above. Patient monitors and wearables that use Bluetooth run the SCO path in CVE-2026-89774, and a Bluetooth bug is reachable by anyone within radio range of a ward. Any network-connected device that carries DICOM or HL7 traffic runs the core socket buffer path in CVE-2026-90049. Equipment that mounts a clinical data share is in scope for the NFS client records CVE-2026-90104 and CVE-2026-90151 and for the SUNRPC record CVE-2026-90235; a device only has to mount a share to run that code, it does not have to serve one. Devices that mount removable media for imaging or data export also run the ISO9660 and NTFS3 paths in CVE-2026-89778, CVE-2026-90048 and CVE-2026-89779.

Patching a medical device is not the same as patching a server. A kernel change usually triggers validation and, depending on the change and the market, regulatory revalidation under US FDA postmarket cybersecurity guidance, the EU Medical Device Regulation and IEC 62304. So the action here is to raise the stable update through the manufacturer’s change-control process and to record the reachability argument for each record while the evidence is fresh, rather than to patch a fielded device directly.

How to check if a Linux kernel CVE applies to you

Three questions settle it, in this order.

Version. Run uname -r and compare against the table above. If your branch is already at or past the listed version, this week’s set is covered and you can stop.

raghu@techveda.org:~$ uname -r
6.6.152

Configuration. Most of these records only exist in your binary if the relevant option was built. Check the symbol named in each section against your running config:

raghu@techveda.org:~$ zcat /proc/config.gz | grep CONFIG_BT=
CONFIG_BT=m
raghu@techveda.org:~$ zcat /proc/config.gz | grep CONFIG_NTFS3_FS
CONFIG_NTFS3_FS=y

If /proc/config.gz is not present, the same information is in /boot/config-$(uname -r) on most distributions, or in the .config used for your build.

raghu@techveda.org:~$ grep CONFIG_NVME_TARGET_TCP /boot/config-$(uname -r)
CONFIG_NVME_TARGET_TCP=m

Reachability. This sets the order of work. Put anything reachable over the air or over the network first, because it needs no foothold: the NVMe-oF, ksmbd, nfsd, iSER, SUNRPC and IPsec records fall here, as does the Bluetooth record on a device with a radio. Next take local unprivileged paths, which need an account or a process on the device but no special rights, such as the filesystem parsing records when a user can insert media. After that, guest to host, which matters only on shared hosts running nested guests. Last come records that need root or a configuration you do not ship.

Key takeaways

• 878 CVE records were published in this window, 876 after two rejections. That is about double last week, but with fewer CRITICAL records: 35 against 54.
• Update to 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, 6.18.52 or 7.2.6 depending on your branch. Each of these is the newest release on its branch, so the table cannot move.
• The 7.1 branch is end-of-life at 7.1.13. It receives no fixes from this set. Plan a move to 7.2.
• Everything here is already fixed in mainline. No record notes known exploitation and no public exploit code was found at the time of writing.
• 559 of the 878 records carry no CNA score. Unscored does not mean harmless. Order the work by reachability and by what your product builds.
• If you serve NVMe over Fabrics, SMB through ksmbd, NFS, CephFS or iSER, this is a heavier week than the record count alone suggests, because that is where the CRITICAL records cluster.
• The CVE IDs in this window are not one continuous run. If you script against the range, read the IDs rather than computing them.

Frequently asked questions

How many Linux kernel CVEs were published in this window?
878 records were published between 13 and 19 September 2026. Two of them were rejected, so 876 stand. Of those, 35 carry a CRITICAL score from the kernel CNA and 284 carry a HIGH score.

Is any of this being exploited right now?
No record in this set notes known exploitation, and no public exploit code was found for any of them at the time of writing. Every record already has a fix in mainline. This is scheduled maintenance work, not an incident.

I am on 7.1. What should I do?
The 7.1 branch reached end of life with 7.1.13 on 2 September 2026, and no record in this week’s set names a 7.1 fixed version. There is no patch to apply. The work item is planning a move to 7.2.

Do I need to act on all 878 records?
No. Updating to the minimum safe version for your branch clears the whole set for that branch. The per-record detail matters when you need to justify a delay, or when you are on a vendor kernel that cannot simply take the stable update.

Why do so many records have no severity score?
The kernel CNA assigns a CVSS score to some records and not others. This week 559 of 878 have no score. An unscored record can still be serious. Judge by whether the code is built into your product and who can reach it.

Does a device that only mounts a network share need patching?
Yes, in some cases. The NFS client records in this set are reached through the callback channel, and the Ceph records are reached by a machine that mounts CephFS. Mounting a share is enough to run that code. You do not have to be serving one.

Further reading

• linux-cve-announce mailing list archive — where the kernel CNA announces each record
• Kernel documentation: CVEs — how and why the kernel project assigns them
• kernel.org active releases — current version and end-of-life date for every branch
• cve.org — the individual records linked throughout this post