Linux Kernel CVEs: What to Patch by Device (6 – 12 Sep 2026)

443 records is a high weekly volume for this project. Last week was 188. The IDs are not one continuous block this week: they run from CVE-2026-80914 to CVE-2026-81018, then continue in a second block from CVE-2026-89436 upward.

Most of these fixes are narrow. Which of these Linux kernel CVEs matter for you depends on what your product builds and how it is configured. A phone, an industrial gateway, a storage server and a patient monitor build different code, so they are exposed to different parts of this list. The kernel CNA scores only some records, and NVD has not finished analysing the batch, so order your work by reachability and deployment context rather than by score alone. This week 174 of the 443 records carry a score, and 54 of those are CRITICAL, which is far above a normal week. Where a score is quoted below it is the one the kernel CNA assigned. NVD may show no score for the same record until its own analysis completes, so the two will not always agree yet. This advisory gives the version to install first, then explains which records matter for mobile and automotive, embedded and IoT, cloud and datacenter, and medical devices. Each record below has its own heading, so you can link straight to it.

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

Find the kernel version each product is running, compare it with the target for its branch in the table below, and update if it is lower. A system on 6.12.105, for example, is below the 6.12 target of 6.12.109 and needs the update.

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

Branches not listed here, meaning 5.4 and older, had no fix backported from this window. Either they do not contain the affected code or the fix predates the window.

One dated item to plan around, separate from this week’s records. kernel.org projects both 5.10 and 5.15 to reach end of life in December 2026, which is about three months away. A lot of embedded product still ships on 5.10. When those branches stop, they stop the same way 7.1 did earlier this month: the last release stays fully patched as of its date, and every kernel CVE published afterwards against code the branch contains stays unfixed on it. If you are on 5.10 or 5.15, the update in the table is this week’s job and choosing the next branch is this quarter’s job. The longterm options with the longest remaining window are 6.12 and 6.18, both projected to December 2028.

Two cautions on this table. First, it is built from the fixed-version data in this window’s records, so treat it as the lowest release that is known to be safe rather than a guarantee that nothing higher is needed. Check the current release for your branch on kernel.org before you schedule the work. Second, a number of records this week mark a branch as affected without naming a fix for it. The clearest case is CVE-2026-89537, described below, which is fixed in 7.2.4 and mainline only even though the affected code has been present since 2.6.35. For records like that, the branch update is correct but not sufficient, and you need to watch for the stable backport. This is ordinary behaviour for the kernel CNA, which publishes when the mainline fix lands, and the backports usually follow within a few days.

If you run a vendor or BSP kernel, the version string will not compare cleanly with the table. A kernel that reports 6.6.60-imx is based on 6.6.60, and it will not become 6.6.156 by any upstream update you apply yourself. For those products the table tells you which fixes have to be present, not which release to install. Ask your silicon or BSP vendor to confirm, and treat a verified vendor backport as equivalent to the upstream target.

Cloud and datacenter

This is where nearly all of the serious work is this week. 54 records are scored CRITICAL, and they are concentrated almost entirely in code that parses data arriving over a network: NFS server and client, Ceph, the SMB client and the in-kernel SMB server, SUNRPC, and the NTFS3 driver. They share a shape. A length, count or offset taken from the wire is used without being checked, and the resulting pointer arithmetic runs off the end of an allocation.

The volume and the common pattern suggest this was a deliberate audit of network filesystem code rather than an ordinary week of unrelated fixes. Twenty-one of the CRITICAL records are in the NFS server alone, eight in Ceph, seven across the SMB client and ksmbd, ten in SUNRPC and five in NTFS3. Treat the whole group as one update rather than trying to pick individual patches out of it.

Exposure is not limited to serving these protocols. Several records are triggered by a malicious or compromised server against a client that mounts from it, so a machine that only consumes NFS, Ceph or SMB is in scope too. The records below are a representative selection, not the full 54.

CVE-2026-89533: svcrdma offset arithmetic underflow (CVSS 9.8)

This is the highest-scored record of the week. svc_rdma_read_chunk_range() walks a Read chunk’s segment list to build a sub-range for a Position-Zero or Call chunk. It has two arithmetic defects. The skip test uses > where it should use >=, so a segment that is exactly fully consumed falls into the loop body instead of being skipped. And the length cap is applied before the offset is subtracted rather than after. Together these underflow a u32 to a value near UINT_MAX, which then propagates a very large segment count into svc_rdma_build_read_segment() and drives a multi-megabyte allocation. The trigger is a single RPC from anything that can reach the RDMA port, with no authentication. The affected file is net/sunrpc/xprtrdma/svc_rdma_rw.c, so the gate is CONFIG_SUNRPC_XPRT_RDMA. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89536: SUNRPC TLS handshake callback race (CVSS 9.8)

This one is on the client side, so it applies to machines that mount NFS over TLS as well as to servers. xs_tls_handshake_sync() hands a reference to the lower transport to the completion callback, then drops that reference itself if the handshake times out or is interrupted. The problem is that handshake_req_cancel() returns false when the request has already completed, and in that case the callback may still be running. The waiter can therefore free the transport before xs_tls_handshake_done() has finished with it. The affected file is net/sunrpc/xprtsock.c, so the gate is CONFIG_SUNRPC, which is present on any system that uses NFS at all. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89538: SUNRPC krb5 wrap token with oversized ec field (CVSS 9.8)

Read the attacker model on this one carefully, because it is narrower than the score suggests. The 16-bit extra count field in a Kerberos version 2 wrap token is authenticated by the check that runs after decryption, so a random value will be rejected. But any peer that already holds a valid GSS context can legitimately encrypt a token whose extra count is larger than the plaintext. Such a token is malformed under RFC 4121, and the kernel did not reject it, so xdr_buf_trim() left the buffer in an inconsistent state. So the attacker needs a valid Kerberos context first. On a shared cluster where many clients hold contexts against the same server, that is not a high bar. The affected file is net/sunrpc/auth_gss/gss_krb5_wrap.c, so the gate is CONFIG_SUNRPC_GSS. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89537: SUNRPC short krb5 MIC token (CVSS 9.1, no LTS fix yet)

This is the record to watch, for a reason that has nothing to do with its score. gss_krb5_verify_mic_v2() reads the token ID, the flags byte and the padding without first checking the token length. Four separate call paths accept short tokens from the wire, and a malicious NFS server can supply a short checksum that causes a small allocation to be read past. The code has been present since 2.6.35, so every current branch contains it.

The part that matters operationally is the fix coverage. At the time of writing the record names a fix in 7.2.4 and 7.3-rc1 only, and lists no LTS backport. Read that carefully: it means no backport is recorded yet, not that none is coming. These records are updated as stable releases pick the fix up, so the position may have changed by the time you read this. If you run NFS with sec=krb5, sec=krb5i or sec=krb5p on an LTS kernel, check the record directly before you close out the week rather than assuming the branch update in the table above cleared it. The affected file is net/sunrpc/auth_gss/gss_krb5_unseal.c, so the gate is CONFIG_SUNRPC_GSS. See the CVE record.

CVE-2026-89532: svcrdma empty chunk loop underflow (CVSS 9.1)

A parsed chunk list can contain a chunk whose segment count is zero. The loop macro computed its upper bound as the element at index ch_segcount - 1, and because that field is unsigned, zero minus one wraps to 0xFFFFFFFF. The bound then lands far past the end of the array. A chunk advertising zero segments is reachable from the wire because the validation only rejected counts that were too large, not counts of zero. When the transport has negotiated Send-With-Invalidate, the kernel walks unrelated memory until it faults. The affected file is include/linux/sunrpc/svc_rdma_pcl.h, so the gate is CONFIG_SUNRPC_XPRT_RDMA. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

Three more svcrdma records belong to the same group and are cleared by the same update: CVE-2026-89526 (a Read chunk position past the inline body underflows the tail length and copies adjacent memory back to the client), CVE-2026-89530 (an inline reply overflows the pull-up buffer) and CVE-2026-89528 (a Read list larger than the page budget hits a NULL sentinel during DMA mapping). If you run NFS over RDMA, take the branch update rather than picking single patches.

CVE-2026-89633: SMB client out-of-bounds read and write in coalesce_t2 (CVSS 9.8)

This is the one to look at first if you mount SMB shares. coalesce_t2() builds data pointers straight from the DataOffset fields the server supplies, with no bounds checking at all. A small value pushes a pointer below the real byte area and overwrites header fields. A large one pushes it past the end of the buffer. The result is an out-of-bounds heap read on the source side and an out-of-bounds write on the target side. The comment marking that check as needed had been in the file since 2005 without ever being implemented, so every branch contains this. The affected file is fs/smb/client/smb1transport.c, so the gate is CONFIG_CIFS. Fixed in 6.18.51, 7.2.4 and 7.3-rc1. See the CVE record.

Six more SMB client records land alongside it and are cleared by the same update, including CVE-2026-89636 (a dangling cache pointer left by free_tgts()), CVE-2026-89637 (a use-after-free on a malformed secondary T2 response), CVE-2026-89631 (a byte-count underflow that leaks slab memory into /proc/fs/cifs/DebugData) and CVE-2026-89634 (an ALIGN() overflow in the symlink error path).

CVE-2026-89635: ksmbd rebinds another session’s oplock on durable reconnect (CVSS 9.8)

If you run the in-kernel SMB server, this is the priority. On a durable handle reconnect, ksmbd_reopen_durable_fd() walked the inode’s oplock list and rebound every detached oplock to the reconnecting session, not just the one belonging to the file being reopened. Two sessions holding durable handles on the same file are enough: one reconnects and adopts the other’s oplock, then the adopting session is destroyed and freed while the foreign oplock still points at it. The reporter reached it from an authenticated session against a share with default durable-handle and oplock settings. The affected file is fs/smb/server/vfs_cache.c, so the gate is CONFIG_SMB_SERVER. Fixed in 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89658: NFS server use-after-free during revoked-state cleanup (CVSS 9.8)

This is the largest group of the week. Twenty-one CRITICAL records are in the NFS server, and most share one shape: a lock is dropped part-way through walking a list of client state, the client is freed while the lock is down, and the walk resumes on freed memory. This record covers the NFSv4.0 revoked-state cleanup path. Its close relatives are CVE-2026-89659 (delegation revoke), CVE-2026-89660 (administrative state revocation), CVE-2026-89662 (lock owner freed during client teardown) and CVE-2026-89708 (callback session freed while an RPC is still in flight). The gate is CONFIG_NFSD. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89674: NFS server XDR length miscalculation in layoutget (CVSS 9.8)

Worth separating from the use-after-free group because the mechanism is different. The length calculation in nfsd4_ff_encode_layoutget() is wrong, which gives an out-of-bounds write and can disclose memory in the reply. This only applies if you export pNFS with the flexfiles layout. A companion record, CVE-2026-89673, covers a padding mismatch in the related getdeviceinfo encoder that leaks stale reply bytes. The gate is CONFIG_NFSD_PNFS. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89651: Ceph unbounded decode of MDS capability paths (CVSS 9.8)

Eight CRITICAL records are in the Ceph client and libceph, and they are all the same class: a length or count is read from a message sent by the metadata server or monitor and used without an upper bound. This one covers the capability path and filesystem name in handle_session(). Others in the group include CVE-2026-89652 (dentry name length on NFS re-export), CVE-2026-89653 (export target ranks past the maximum), CVE-2026-89656 (CRUSH bucket id mismatch) and CVE-2026-89649 (xattr value length). The attacker model is the Ceph cluster the client is talking to, which matters most where that cluster is not fully trusted. The gate is CONFIG_CEPH_FS. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89541: SUNRPC integer overflow in gss_unwrap_resp_priv (CVSS 9.8)

A client-side record, and a good illustration of why mounting is as exposed as exporting. The opaque length check adds two unsigned 32-bit values and compares the sum, so a length near 0xffffffff wraps to a small number and passes. There is no lower bound either, so a length below the 16-byte Kerberos header is accepted and handed on. A krb5p NFS server returning a crafted reply drives the client into out-of-bounds reads. The affected code has been present since 2.6.15. Its companion CVE-2026-89542 hardens the unwrap core itself against short tokens, including a divide-by-zero and a near-4GiB memmove(). The gate is CONFIG_SUNRPC_GSS. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89610: NTFS3 run length exceeding the volume boundary (CVSS 9.8)

Five CRITICAL records cover the NTFS3 driver, all of them validation of structures read from the volume: run lengths past the end of the volume, non-resident attribute offsets, invalid MFT cluster numbers, empty mapping pairs, and an unbounded free-cluster bitmap scan. The trigger is mounting a crafted or corrupted NTFS filesystem, so the exposure is removable media and any workflow that mounts untrusted images. All five were introduced in 7.1, so older branches do not contain this code, and all five are fixed only in 7.2.4 and mainline. The gate is CONFIG_NTFS3_FS. See the CVE record.

CVE-2026-89555: MPLS use-after-free when reloading a pulled header (CVSS 9.8)

One of the few CRITICAL records this week outside the filesystem and RPC group. mpls_multipath_hash() caches a header pointer while walking the label stack, then calls pskb_may_pull() before reading the inner IP header. On a non-linear packet that call can replace the socket buffer head and free the old one, leaving the cached pointer dangling. A reproducer sending an ordinary Geneve packet through a bareudp and MPLS multipath setup hit it in two runs out of two. This matters on routers and any edge device doing MPLS forwarding. The affected file is net/mpls/af_mpls.c, so the gate is CONFIG_MPLS_ROUTING. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89558: md RAID10 recovery clears the wrong bitmap bits (CVSS 9.8)

Not a memory-safety bug, and worth reading carefully because the consequence is silent. A boolean conversion inverted a flag, so recovering one device while another mirror is still missing clears bitmap bits that the still-missing device needs. When that device is re-added its recovery finds the bits already cleared, skips every region written while the array was degraded, and is then marked in sync while holding stale data. The reproducer reports a mismatch count of 262272 after 256 MiB of degraded writes, with the second disk’s recovery completing in milliseconds because everything was skipped. The affected file is drivers/md/raid10.c, so the gate is CONFIG_MD_RAID10. The bug was introduced in 6.12. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-80921: KVM on s390 leaves stale crypto bits in vsie (CVSS 8.8)

This crosses the guest-to-host boundary, which is why it belongs near the top on any s390 host running nested guests. The CVSS vector marks a scope change, meaning a guest can affect state outside its own security boundary. It also has the widest backport of any record this week, reaching every active branch, and it is what sets the 5.10, 5.15, 6.1, 6.6 and 7.1 targets in the table above. The affected file is arch/s390/kvm/vsie.c, so the gate is CONFIG_KVM on s390. Fixed in 5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.108, 6.18.49, 7.1.13, 7.2.3 and 7.3-rc1. See the CVE record.

CVE-2026-89513: RISC-V KVM PMU event count overflow

The guest supplies a number of PMU events. That value truncates in 32-bit arithmetic, so KVM allocates one array entry but then loops over the full untruncated count, reading and writing out of bounds on the host. This is a guest-to-host escape shape on RISC-V hosts. The code was introduced in 6.18, so older branches do not contain it, but note that the fix is named for 7.2.4 and mainline only, so 6.18 is affected with no backport listed yet. The affected file is arch/riscv/kvm/vcpu_pmu.c, so the gate is CONFIG_KVM on RISC-V. See the CVE record.

CVE-2026-80994: openvswitch flow mask use-after-free

Reported through the Zero Day Initiative as ZDI-CAN-32042. The flow delete command removes the flow before ovs_flow_cmd_fill_info() reads flow->mask. If an RCU grace period falls between the two, the read touches freed memory. This matters on any host running Open vSwitch, which on most deployments means every hypervisor and every container host using an OVS-backed network. The affected file is net/openvswitch/datapath.c, so the gate is CONFIG_OPENVSWITCH. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89488: openvswitch connection tracking teardown use-after-free

The exposure here is different from the record above, and worse in one specific way: it is reachable by an unprivileged user who can create a user namespace and a network namespace. On a container host that allows unprivileged user namespaces, that is any workload. The bug is a use-after-free in ovs_ct_execute() during namespace teardown. The affected files are in net/openvswitch/, so the gate is CONFIG_OPENVSWITCH. Fixed in 6.18.51, 7.2.4 and 7.3-rc1. A companion record, CVE-2026-89487, covers a related problem where a failed upcall strips the shared-fragment flag from a packet that is still being forwarded. See the CVE record.

CVE-2026-89481: nvme-tcp host memory disclosure via R2T

A malicious or faulty NVMe over TCP target sends a Ready to Transfer for a read command, and the host transmits stale kernel page contents back to it. The attacker model is the storage target, so this matters where the target is not fully trusted, which includes multi-tenant storage fabrics. Two companion records cover the same driver: CVE-2026-89482, where data accepted on a stale iterator produces a wild memory write, and CVE-2026-89480, where a short read is completed as if it were full and hands user space stale page data. The affected file is drivers/nvme/host/tcp.c, so the gate is CONFIG_NVME_TCP. All three are fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-80982: net/smc use-after-free on concurrent close

Shared Memory Communications is used for high-throughput socket traffic, mostly on IBM Z and on RDMA fabrics. This record is one of eight in the subsystem this week. The socket state is tested before the lock is taken, so a concurrent close can free the receive buffer descriptor and the link group that the code then walks. The other seven cover related problems in the same area, including two out-of-bounds reads of peer-supplied rkey counts in SMC-Rv2 link setup, CVE-2026-80985 and CVE-2026-80986. If you use SMC, take the branch update for the group. The affected file is net/smc/smc_rx.c, so the gate is CONFIG_SMC. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-81002: xdp zero-copy frame layout overlap

An AF_XDP zero-copy packet redirected through cpumap can end up with the socket buffer overlapping the shared info structure, or running past the end of the page. The result is an out-of-bounds write during GRO receive. This applies to hosts running AF_XDP zero-copy, which in practice means high-performance packet processing and load balancers. The affected file is net/core/xdp.c, so the gate is CONFIG_XDP_SOCKETS. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-81009: io_uring query allows a very large clear_user

An unclamped 32-bit size field lets a query request nearly 4 GiB of clear_user(). What makes this one notable is the reachability: it can be triggered through IORING_REGISTER_QUERY without setting up a ring at all, so the usual assumption that io_uring exposure follows ring creation does not hold. The code was introduced in 6.18. The affected file is io_uring/query.c, so the gate is CONFIG_IO_URING. Fixed in 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

Mobile and automotive

The records that matter here are the ones driven by radio traffic or by an attached device, because those are reachable without any foothold on the system. One Bluetooth record stands out this week, and the wireless driver group is large.

CVE-2026-80914: Bluetooth ISO listener socket use-after-free (CVSS 8.8)

This is the most serious over-the-air record of the week. iso_conn_ready() looks up the broadcast listener socket, takes a reference, then creates a child socket from it without re-checking the parent’s state after taking the lock. If the listener is closed at the same moment, the reference taken can be the last one. The child socket is then linked to a parent that has been freed, and a later disconnect of the child dereferences the dangling pointer. The CVSS vector is adjacent network with no privileges and no user interaction, which means an attacker in Bluetooth range and no pairing step.

This matters for in-vehicle infotainment and for any handset or wearable using isochronous channels, which is what LE Audio uses. The fix follows the same pattern as the earlier fix for the connected path, commit 0d255e63fcf3: after taking the lock, confirm the parent is still a live listening socket. The affected file is net/bluetooth/iso.c, so the gate is CONFIG_BT. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-80918: HID core type confusion on long items

The HID core confuses a number for a pointer when parsing long items in a report descriptor. The descriptor comes from the device, so this is reachable from any malicious USB or Bluetooth HID peripheral. In a vehicle that means anything plugged into an accessible USB port, and on a handset it means a paired or pairable input device. The code has been present since 3.12, so every branch is affected, and this record has one of the widest backports this week. The affected file is drivers/hid/hid-core.c, so the gate is CONFIG_HID. Fixed in 5.10.267, 5.15.218, 6.1.185, 6.6.154, 6.12.106, 6.18.47, 7.1.11, 7.2.1 and 7.3-rc1. See the CVE record.

CVE-2026-89524: ath6kl association length underflow leaks kernel memory

An association frame shorter than its own fixed header offset underflows an 8-bit length field. About 250 bytes of adjacent kernel slab memory are then copied out to user space through nl80211. The input is an over-the-air frame, so no association or key exchange is needed first. The leaked bytes are whatever happened to be next to the allocation, which is the classic shape for defeating address randomisation before a second attack. The affected file is drivers/net/wireless/ath/ath6kl/cfg80211.c, so the gate is CONFIG_ATH6KL. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-80943: rtl8192du unchecked QoS TID used as an array index

The traffic identifier field is taken from a received frame and used to index an array without being validated first. That is an out-of-bounds index driven directly by over-the-air traffic. This driver appears in low-cost USB Wi-Fi modules, which show up in aftermarket and retrofit automotive designs more often than in factory-fitted ones. The affected file is drivers/net/wireless/realtek/rtlwifi/rtl8192du/trx.c, so the gate is CONFIG_RTL8192DU. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

The MediaTek group is large again this week. CVE-2026-80936 and CVE-2026-89523 both cover work items in the mt7925 driver that are not cancelled on stop, leaving a window where they touch interface state that may already be freed. CVE-2026-80935 and CVE-2026-80937 add a missing bounds check before an EFUSE copy on mt7996 and mt7915. These are driver lifetime and bounds fixes rather than remote attack paths, but if you ship an mt76 part, take the group in one update.

CVE-2026-89725: HDMI CEC out-of-bounds write on the STM32 controller (CVSS 8.8)

This is the most directly relevant new record for infotainment. The receive index in the STM32 CEC driver is not bounded, so a peer on the HDMI CEC bus can write past the end of the 16-byte message buffer. CEC is the control channel that runs alongside HDMI, so the attacker is anything plugged into the port: a display, a stick, a passenger device. The CVSS vector is adjacent network with no privileges and no user interaction. The affected file is drivers/media/cec/platform/stm32/, so the gate is CONFIG_CEC_STM32. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89569: Bluetooth RFCOMM use-after-free in security confirmation (CVSS 8.8)

A second over-the-air Bluetooth record, alongside the ISO one above. The session lookup and the walk of its data link connections happen without holding the RFCOMM mutex, giving a use-after-free in rfcomm_security_cfm() that KASAN reports as a slab use-after-free. RFCOMM is the serial port profile, so this affects hands-free, phone-book access and any serial-over-Bluetooth profile a head unit exposes. The code has been present since 3.10. The affected file is net/bluetooth/rfcomm/core.c, so the gate is CONFIG_BT_RFCOMM. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89583: Bluetooth out-of-bounds read in extended inquiry response parsing (CVSS 8.1)

A length accounting drift lets eir_get_service_data() read past the advertising data buffer, and the result is reachable from user space through getsockopt(BT_ISO_BASE). The input is an advertising packet, so no connection or pairing is needed. Together with CVE-2026-80914 above, this means three separate over-the-air Bluetooth records this week. If you ship Bluetooth, take the branch update rather than picking patches. The affected file is net/bluetooth/eir.c, so the gate is CONFIG_BT. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89729: HID sensor hub out-of-bounds write from a crafted descriptor (CVSS 8.8)

A malicious HID report descriptor causes an out-of-bounds write in sensor_hub_get_feature(). This is the same attacker model as the HID core record above, an attached or paired input device, but it applies specifically to designs that use the HID sensor hub for accelerometers, gyroscopes and ambient light sensors, which is common in automotive and in tablets. The affected file is drivers/hid/hid-sensor-hub.c, so the gate is CONFIG_HID_SENSOR_HUB. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-80997: IPA modem transmit queue stalls after runtime resume

A wake signal consumed while the device is resuming leaves the cellular data path stalled in both directions. There is no transmit timeout watchdog on this path, so nothing recovers it automatically. This is an availability problem rather than a memory safety one, but on a telematics unit or a connected vehicle the practical effect is that the modem goes silent until the interface is cycled. That is worth knowing about before a fleet reports it. The affected file is drivers/net/ipa/ipa_modem.c, so the gate is CONFIG_QCOM_IPA. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

Embedded and IoT

The records here are driven by attached hardware, by an embedded controller, or by a local process. Several are in buses that only embedded designs use, so they will not appear on a general-purpose server at all.

CVE-2026-80916: kcov data corruption on PREEMPT_RT

A race in kernel coverage instrumentation corrupts state on PREEMPT_RT kernels. This is worth calling out for industrial and real-time products specifically, because PREEMPT_RT is exactly where those products live and the bug does not affect a normal preemption model in the same way. The code has been present since 5.8 and this record has one of the deepest backports of the week. The affected files are kernel/kcov.c and include/linux/sched.h, so the gate is CONFIG_KCOV. Many production images build without it, and those are not exposed. Fixed in 5.10.269, 5.15.220, 6.1.185, 6.6.154, 6.12.106, 6.18.47, 7.1.11, 7.2.1 and 7.3-rc1. See the CVE record.

CVE-2026-81017: ChromeOS sensorhub unbounded sensor number

The sensor number comes from the embedded controller and is not bounded before use, giving an out-of-bounds read and write. The input is the EC, so the trust boundary here is the firmware on the companion controller rather than anything on the network. That still matters on any design where the EC firmware is separately updatable or separately sourced. The affected file is in drivers/platform/chrome/, so the gate is CONFIG_CROS_EC_SENSORHUB. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89470: cros_usbpd port count overflows the ports array

The same trust boundary as the record above, in the USB Power Delivery charger driver. The port count reported by the embedded controller is not bounded, so it overflows the driver’s array. A companion record, CVE-2026-89471, covers the same problem in the charger half of the driver. This sits inside a group of fifteen power supply records this week, most of which are work items that keep running after the device has been removed. If your product uses any of the drivers in drivers/power/supply/, the branch update is the efficient way to take the whole group. The gate is CONFIG_CHARGER_CROS_USBPD. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-80951: i3c IBI payload not bounded to the requested maximum

An in-band interrupt payload from a device on the bus is not clamped to the maximum payload length the driver asked for. The attacker model is a device on the I3C bus, so this matters where the bus is exposed on a connector or where a component is field-replaceable. Four more i3c records land the same week, including CVE-2026-80952, an information leak and use-after-free in the device unregister path. The affected file is in drivers/i3c/master/, so the gate is CONFIG_I3C together with the specific master driver. Fixed in 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-80931: w1 ds28e17 accepts an oversized I2C block read length

A length field is not rejected when it exceeds the buffer, in a 1-Wire to I2C bridge driver. This is a small driver used in sensor and identification designs. It is listed here because the pattern is the one to look for on any bus bridge: a length that crosses from one bus into a buffer sized for the other. The affected file is drivers/w1/slaves/w1_ds28e17.c, so the gate is CONFIG_W1_SLAVE_DS28E17. Fixed in 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89733: USB gadget UVC dangling pointers after unbind (CVSS 7.8)

Relevant to any product that presents itself as a USB device rather than a host, which covers cameras, industrial sensors and anything exposing a gadget interface. The control request and buffer pointers are left dangling after being freed in bind and unbind, giving a use-after-free. Four more USB gadget records land the same week: CVE-2026-89736 (audio gadget freed while ALSA controls are still open), CVE-2026-89738 (a polled-VBUS timer outliving the freed controller on AT91), CVE-2026-89732 (a deadlock between an ep0 read and configfs teardown) and CVE-2026-89739 (a work item racing endpoint teardown on dwc3). The gate is CONFIG_USB_CONFIGFS together with the specific function driver. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89727: KVM on arm64 guest-triggered warning in the virtual interrupt controller

For anyone running virtual machines on arm64, which now includes a good deal of automotive and telecom equipment. A guest writing an interrupt ID outside the valid range to the vGICv2 deactivation register triggers a kernel warning. On a host built with panic_on_warn, which hardened and safety-oriented builds often use, that warning takes the host down. So the practical effect is a guest-to-host denial of service on exactly the configurations most likely to care. The gate is CONFIG_KVM on arm64. Fixed in 7.2.4 and 7.3-rc1. See the CVE record.

CVE-2026-89489: openrisc or1k_atomic syscall gives arbitrary kernel access

An unprivileged process passes kernel addresses to system call 244 and gets a kernel read and write primitive, which is enough to overwrite the system call table. This is a straightforward local privilege escalation. It only applies to OpenRISC, which is a narrow deployment base, but if you are on that architecture this is the first item on the list and not the last. The code has been present since 3.1. The affected file is arch/openrisc/kernel/entry.S. Fixed in 6.12.109, 6.18.50, 7.2.4 and 7.3-rc1. See the CVE record.

Two more groups are worth a mention for embedded images. The ALSA group of ten records covers unchecked card index values at probe time across several MIDI and sound drivers, plus one kernel memory leak to user space in CVE-2026-80970. The dm-pcache group of eight records validates on-disk metadata that was previously trusted, which matters if you use that caching target on removable or untrusted media.

Medical devices

Several records from the sections above apply directly to connected clinical equipment, and none of them needs a foothold on the device first. Three are over-the-air Bluetooth records: CVE-2026-80914, the listener socket use-after-free reachable from radio range with no pairing; CVE-2026-89569, the RFCOMM use-after-free, which matters wherever a serial profile is exposed; and CVE-2026-89583, an out-of-bounds read driven by an advertising packet. Between them they cover wearables, patient monitors and any device using LE Audio. CVE-2026-89524 leaks kernel memory from a Wi-Fi association frame, which applies to any device on a hospital wireless network. CVE-2026-80918 and CVE-2026-89729 are the HID parsing bugs, reachable from an attached peripheral, covering bedside scanners, keyboards, card readers and sensor hubs.

The network filesystem group matters here more than it might first appear. Clinical data moves over exactly these protocols. CVE-2026-89536 is the SUNRPC TLS handshake race, and CVE-2026-89541 lets a malicious NFS server attack a client that mounts from it. DICOM image stores and HL7 or FHIR integration hosts commonly mount NFS or SMB, so a device that only reads from a share is in scope, not just the server.

The practical difficulty in this vertical is not identifying the patch. It is that medical device patching is gated by validation and regulatory revalidation under US FDA postmarket cybersecurity guidance, EU MDR and IEC 62304, so a kernel update cannot simply be applied. The action is to plan the stable update through the manufacturer’s change-control process, record the applicable records above against the device’s software bill of materials, and use the reachability notes to argue the priority. Most of the records named in this section do carry a CNA score this week, which makes that argument easier to make than usual.

How to check if these Linux kernel CVEs apply to you

Three questions, in this order. Each one can rule a record out, so working through them in order saves time.

First, version. Find the running kernel version and compare it with the target for its branch in the table above.

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

Second, configuration. A record only applies if the affected code was built into your kernel. Every record above names its CONFIG_* gate. Check it against the running configuration.

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

If /proc/config.gz is not present, the configuration is usually in /boot instead.

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

A result of =y means the code is built in, =m means it is a module that may or may not be loaded, and a result of is not set means the record does not apply to that image at all.

Third, reachability. This is what sets the order of work. Put anything an attacker can reach over a radio or a network without credentials first, because there is no precondition to argue about. Then local unprivileged memory corruption, because any code running on the device can reach it. Then guest-to-host, which matters on shared hosts. Then anything that needs privileges or a specific configuration already in place, because those need an attacker to be there already.

Applied to this week, that ordering puts the network filesystem group first, because most of the 54 CRITICAL records are there and nearly all are reachable without credentials. The over-the-air records come next: CVE-2026-80914, CVE-2026-89569, CVE-2026-89583 and CVE-2026-89725. Then the local memory corruption in openvswitch and io_uring, then the virtualization records, then the driver hardening groups.

Key takeaways

• Update to at least 5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.109, 6.18.51, 7.1.13 or 7.2.5, depending on your branch. Confirm against kernel.org before scheduling the work.
• Unlike last week, the branch update does not clear every record. Several name a fix on 7.2 and mainline only while still marking older branches affected. CVE-2026-89537 is the clearest example and it has no LTS fix yet.
• 54 records are scored CRITICAL, almost all of them in network filesystem and RPC code: the NFS server, Ceph, the SMB client and ksmbd, SUNRPC and NTFS3. Most are reachable over the network without credentials, and several are triggered by a malicious server against a client, so mounting these protocols exposes you as well as serving them.
• The pattern across those 54 records is the same: a length, count or offset taken from the wire used without a bounds check. It reads as a deliberate audit of network filesystem code rather than an ordinary week, so take the branch update as one change instead of picking individual patches.
• CVE-2026-80914 is the one to act on for devices with a radio. It is reachable from Bluetooth range with no pairing and no user interaction.
• 7.1 remains end of life at 7.1.13, which was released on 2 September 2026. Records in this window that are fixed only on newer branches will never be fixed on 7.1, so a migration plan is now the work, not another update.
• 5.10 and 5.15 are both projected to reach end of life in December 2026. If you ship either one, start choosing the next branch now. 6.12 and 6.18 both run to December 2028.
• 174 of the 443 records carry a score, and those scores come from the kernel CNA rather than NVD’s own analysis, which is still pending. For the rest, order the work by reachability and by what your build actually enables.

Frequently asked questions

Is any of this being exploited right now?
No. None of the records in this window 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.

Why are there 443 records this week when last week had 188?
The count depends on when stable releases land and when the CNA publishes the batch, not on how much is wrong with the kernel, so volume alone is not a severity signal. This week is an exception worth noting: the volume came with 54 CRITICAL records concentrated in network filesystem and RPC code, which is far above a normal week and looks like a deliberate audit of that code.

Most of these have no CVSS score. Does that mean they are low severity?
This week is the other way round. 174 of the 443 records carry a score from the kernel CNA, and 54 of those are CRITICAL. NVD has not finished its own analysis, so its pages may still show no score for the same records. Where a record genuinely has no score, use the reachability and configuration questions above to set priority instead.

I updated to my branch target. Am I finished?
Not quite, this week. A number of records name a fix only on 7.2 and mainline while still listing older branches as affected. Check the records flagged above, in particular CVE-2026-89537, to see whether the stable backport has landed since publication.

My kernel version does not match anything in the table. What now?
You are probably on a vendor or BSP kernel. A kernel reporting 6.6.60-imx is based on 6.6.60 and will not become 6.6.156 through any upstream update you apply. For those products the table tells you which fixes must be present. Ask your silicon or BSP vendor to confirm, and treat a verified vendor backport as equivalent to the upstream target.

We ship a medical device and cannot patch quickly. What should we do first?
Record the applicable records named in the medical section against the device software bill of materials, then plan the stable update through the manufacturer’s change-control process. Regulatory revalidation under FDA postmarket guidance, EU MDR and IEC 62304 means the update is a planned change, not an emergency one. Use the reachability notes to argue the priority.

We are still on 7.1. Is 7.1.13 enough?
7.1.13 is the final 7.1 release, so it is as patched as that branch will ever be. Some records in this window are fixed only on newer branches and will never be backported to 7.1. Plan a move to 7.2, which is the current stable series, or to a longterm branch such as 6.18 if you prefer to change kernel version rarely.

Further reading

• linux-cve-announce mailing list archive — where every kernel CVE is announced.
• kernel.org — current release for each stable and longterm branch.
• Kernel CVE process documentation — how and why the kernel project assigns CVEs.
• cve.org — individual records, linked throughout this advisory.
• Linux stable git tree — the commit behind each fix.