Raghu Bharadwaj

Posted on Sep 5 Originally published at techveda.live

Linux Kernel CVEs: What to Patch by Device (30 Aug - 5 Sep 2026)

#linux #kernel #security #embedded

Originally published on TECH VEDA: Linux Kernel CVEs: What to Patch by Device (30 Aug - 5 Sep 2026). This is a weekly series. Every CVE below was read from the CVE Program record, and the branch targets were checked against kernel.org.

The Linux kernel project published 188 Linux kernel CVEs in the week of 30 August to 5 September 2026. Every one of them is already fixed in a stable release. This week, no record marks a branch as affected without also naming a fixed version for it, so the branch update clears the whole set. None of the records notes known exploitation, and no public exploit code was found for any of them at the time of writing. The only action is to update to the fixed version for your branch. The minimum safe upstream release per branch is 5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.108, 6.18.49, 7.1.13 or 7.2.3. One extra item this week: the 7.1 branch reached end of life with 7.1.13, so it will get no further fixes and needs a migration plan, not just an update.

188 records is close to a normal weekly volume for this project. Last week was 227, and that was unusual: a full stable cycle landed on one day and the records were published together. This week the count comes from ordinary weekly stable releases. The IDs form one continuous block, CVE-2026-80726 to CVE-2026-80913.

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 hypervisor host and a patient monitor build different code, so they are exposed to different parts of this list. The kernel CNA publishes no CVSS base score for most of these records, and NVD has not finished analysing the batch, so order your work by reachability and deployment context rather than by score. 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.104, for example, is below the 6.12 target of 6.12.108 and needs the update.

Stable branch	Update to at least	Notes
5.10 LTS	5.10.269	Set by the three USB records that are fixed on every branch: `CVE-2026-80824`, `CVE-2026-80827` and `CVE-2026-80830`.
5.15 LTS	5.15.220	Set by the same three USB records.
6.1 LTS	6.1.187	Set by the same three USB records. This is also the lowest branch that names a fix for `CVE-2026-80852` (kTLS transmit offload).
6.6 LTS	6.6.156	Set by the same three USB records.
6.12 LTS	6.12.108	Set by the same three USB records. This release also carries `CVE-2026-80850` and `CVE-2026-80825`.
6.18 LTS	6.18.49	Set by the same three USB records. The futex and io_uring records are fixed earlier on this branch, in 6.18.47.
7.1 (end of life)	7.1.13	Set by the same three USB records. 7.1.13 clears every record below, but kernel.org marks it as the final 7.1 release, so this branch gets no further fixes.
7.2 stable	7.2.3	Set by the same three USB records. 7.2.3 is also the only release that fixes `CVE-2026-80853`, the SEV record.
mainline	7.3-rc1	The 7.3 merge window opened on 30 August 2026. 7.2, released 16 August 2026, is the current stable series.

Every target above is a release that already exists, so nothing here waits on a future stable release. Each of the eight stable targets is the newest release of its branch, so on an upstream kernel the check is simple: if you are not on the current release for your branch, you are behind. Three records set the target on all eight branches at once, and all three are in the USB stack: CVE-2026-80824 (use-after-free of the USB device structure when a usbfs file is closed), CVE-2026-80827 (out-of-bounds read in the USB serial option driver) and CVE-2026-80830 (a missing lock in the USB core wakeup notification path).

Branches not in the table were not named as affected by any record this week, or their fix was released before this window. The 6.19 and 7.0 series are not active stable branches.

The 7.1 branch reached end of life this week

This is the item to act on beyond the version bump. On 2 September 2026 the kernel project released 7.1.13 and marked the 7.1 branch as end of life. 7.1.13 contains the fixes for every record in this advisory, so installing it is still correct today. But no 7.1.14 will follow. From now on, every kernel CVE published against code that 7.1 contains will stay unfixed on 7.1.

If you ship 7.1, the update is not the whole job. Decide now where the product moves next. The two upstream options are 7.2, which is the current stable series and receives fixes weekly, and 6.18, which is a longterm branch with a much longer support window. A stable series such as 7.2 is supported only until the next one arrives, so if you want to change kernel version rarely, a longterm branch is the safer target. Plan the move through your normal validation process rather than as an emergency change, because 7.1.13 is fully patched as of this week and there is no time pressure.

Separately, mainline has moved on. The 7.3 merge window opened on 30 August 2026, so mainline now reports 7.3-rc1. That does not change anything you need to install; 7.2 is still the current stable series. It is listed here only so the mainline row in the table is not read as a release you should be running.

Last week's targets were 5.10.268, 5.15.219, 6.1.186, 6.6.155, 6.12.107, 6.18.48, 7.1.12 and 7.2.2. Every branch has moved up exactly one point release since then. A system that was current after last week's advisory needs one more update.

One thing improved this week. Last week four records marked a branch as affected and named no fixed version for it, so the branch update did not clear them. This week there are no such records: all 188 name a fix for every branch they mark as affected. The four open items from last week are unchanged, however. CVE-2026-74752 (SCTP), CVE-2026-80551 (s390 vfio-ccw), CVE-2026-74743 (macvlan) and CVE-2026-80635 (wcn36xx Wi-Fi), plus CVE-2026-74582 from the week before, are still unfixed on the older LTS branches. Nothing in this window changes that, so if you track those five, keep tracking them.

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.

Mobile and automotive

Four records this week sit in code paths that matter on a phone, a tablet or a vehicle: Wi-Fi, Bluetooth, the CAN bus and the HDMI display path.

CVE-2026-80825: Wi-Fi mt7925 did not reserve transmit headroom for forwarded frames

The MediaTek mt7925 driver pushes a transmit descriptor and a USB header onto every outgoing frame, and assumes the headroom for them is already reserved. That holds for traffic the device generates itself, because mac80211 reserves hw->extra_tx_headroom. It does not hold for forwarded frames, which go out through ieee80211_8023_xmit() and do not get that reservation. The record shows the result directly: bridge a wired interface to an mt7925u access point, and the first short forwarded frame triggers skb_under_panic and a kernel BUG.

This matters wherever an mt7925 part is used as an access point or a bridge rather than as a plain client, which includes in-vehicle hotspots and tethering. The trigger is ordinary forwarded traffic, not a crafted frame. The fix reserves the headroom in the USB and SDIO transmit path. The affected file is drivers/net/wireless/mediatek/mt76/mt7925/mac.c, so the gate is CONFIG_MT7925U for the USB part and the SDIO build of the same driver. Fixed in 6.12.108, 6.18.49, 7.1.13 and 7.2.3. See the CVE record.

CVE-2026-80762: Bluetooth accept list use-after-free during suspend

When the system suspends, hci_update_event_filter_sync() walks the controller's accept list and sends a synchronous HCI command for each device allowed to wake the host. That walk holds hdev->req_lock, but accept-list updates are serialized by a different lock, hdev->lock. So while the code waits for the controller to answer, remove_device() can take the other lock, unlink the current entry and free it. When the wait finishes, the walk reads the freed entry. KASAN reports a use-after-free.

The window is the controller response time, which is long in kernel terms, so this is a race that can be hit in normal use on a device that suspends often. This is one of seven Bluetooth records this week; CVE-2026-80764 is a closely related use-after-free of the LE list on reset, and CVE-2026-80819 fixes missing locking in the RFCOMM deferred setup accept path. If you ship Bluetooth, take the branch update rather than picking single patches. The affected file is net/bluetooth/hci_sync.c, so the gate is CONFIG_BT. Fixed in 6.1.187, 6.6.156, 6.12.108, 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80889: CAN ISO-TP timer and wakeup ordering

ISO-TP is the CAN transport protocol used for diagnostics and for any message longer than eight bytes, so it is present on most vehicle and heavy-equipment stacks. This record fixes four ordering problems in the socket code: a stale timer callback could re-arm another timer after a transfer was claimed, a sleeping sendmsg() could be left waiting after the socket was shut down, the wait loops did not wake on shutdown, and the shutdown path could be corrupted by a concurrent transfer claim.

Read the version data on this one carefully, because it is a follow-up. The record lists each branch as affected only from the point release two or three steps before the fix. On 5.10 the affected range is 5.10.265 to 5.10.267, on 6.1 it is 6.1.183 to 6.1.185, and so on. That means the bug was introduced by the previous CAN ISO-TP locking fix, not by old code. If you took that earlier CAN update, you need this one as well. If you are on an older release than that, this record does not apply to you, but the branch target still does. The affected file is net/can/isotp.c, so the gate is CONFIG_CAN_ISOTP. Fixed in 5.10.267, 5.15.218, 6.1.185, 6.6.151, 6.12.103, 6.18.44 and 7.1.8. See the CVE record.

CVE-2026-80749: out-of-bounds read copying an HDMI audio infoframe

A helper copied an audio infoframe into the connector's stored copy using the size of the destination rather than the size of the source. The destination is a generic buffer sized to hold many different kinds of data block, so the copy read 60 bytes out of a 28-byte allocation. The fix uses the source size and adds a build-time check that the source is not larger than the destination.

Keep this one in proportion. It is a read, not a write, so it cannot corrupt memory, and the record says a real-world failure is unlikely; it was found running KUnit tests under KASAN. It is listed here because it is in the display sink path, which matters for infotainment and instrument-cluster designs that drive external HDMI sinks. The affected file is drivers/gpu/drm/display/drm_hdmi_state_helper.c, so the gate is CONFIG_DRM_DISPLAY_HDMI_STATE_HELPER. Fixed in 6.12.105, 6.18.46 and 7.1.10. See the CVE record.

Embedded and IoT

Gateways, routers, single-board computers and battery-powered sensors are affected through the cellular modem driver, the NFC stack, the HID core and the in-kernel OpenVPN data path.

CVE-2026-80827: out-of-bounds read in the USB serial option driver

This is the record most embedded products should read first, because the option driver is what binds to almost every USB cellular modem. The driver sizes its interrupt buffer from the endpoint's wMaxPacketSize. If a device declares wMaxPacketSize = 8, the buffer comes from the 8-byte slab cache. When that device then sends a short packet, the completion handler still reads data[8], which is one byte past the end of an 8-byte allocation. That is a slab out-of-bounds read. The fix adds the missing bounds check.

The input is the attached modem, so the exposure depends on whether the modem is a fixed soldered part or a field-replaceable USB device. On a gateway with an accessible USB port, the attacker model is somebody plugging in a device. This record is also one of the three that set this week's target on every branch. The affected file is drivers/usb/serial/option.c, so the gate is CONFIG_USB_SERIAL_OPTION. Fixed in 5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.108, 6.18.49, 7.1.13 and 7.2.3. See the CVE record.

CVE-2026-80795: out-of-bounds write in the NFC NCI target list

The NCI layer keeps discovered NFC targets in a fixed-size array. nci_target_auto_activated() appends a target and increments the counter without first checking whether the array is full. Its sibling function does check. The counter is only cleared by an explicit call, so an NFC controller that keeps re-running discovery and reporting an auto-activated target drives the counter past the array size. The append then writes a target structure past the end of the array. That is a slab out-of-bounds write, which is the more serious class of the two.

The input comes from the NFC controller, and the controller is driven by whatever tag or reader is held near the antenna. So the range is short, but no pairing or authentication is involved. The affected file is net/nfc/nci/ntf.c, so the gate is CONFIG_NFC_NCI. Fixed in 5.10.267, 5.15.218, 6.1.185, 6.6.154, 6.12.106, 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80799: out-of-bounds read and offset wrap in the NFC LLCP parsers

The LLCP TLV parsers contain three related bugs. The loop offset is declared as an 8-bit value while the total length is 16-bit, so once the walk passes 255 the offset wraps to zero and the loop either repeats data or does not terminate. The type and length bytes are read without checking that two more bytes are available. And the value bytes are read without checking that the declared length fits in the buffer, so a declared length of 255 on a short buffer reads up to 255 bytes past the end.

This one is worth a note for anyone on an older LTS branch: the record lists the problem as reaching back to 5.10.188, 5.4.251 and 4.19.291, so it is long-standing code rather than a recent regression. Ten more NFC records land in the same week, the rest of the CVE-2026-80794 to CVE-2026-80803 block plus CVE-2026-80823, and they are all input validation in the same area. If your product has an NFC radio, treat the group as one update. The affected file is net/nfc/llcp_commands.c, so the gate is CONFIG_NFC. Fixed in 5.10.267, 5.15.218, 6.1.185, 6.6.154, 6.12.106, 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80781: out-of-bounds read in the HID core

hid_set_field() passes field->usage + offset to the input dumping helper before the check that bounds offset. The usage array is allocated inline with the field structure and holds a fixed number of entries, so an offset past the end reads into a neighbouring object. Moving the bounds check ahead of the call fixes it, because the check already confines the offset to the array.

The reachability depends on one build option: the dumping helper only dereferences the pointer when CONFIG_DEBUG_FS is enabled. Production embedded images often build without debugfs, and those images are not exposed through this path. The affected file is drivers/hid/hid-core.c, so the gates are CONFIG_HID together with CONFIG_DEBUG_FS. This is one of 14 HID records this week, including CVE-2026-80780 (an out-of-bounds write when the device has no input) and CVE-2026-80783 (unbounded recursion parsing a Magic Mouse report). Fixed in 5.10.267, 5.15.218, 6.1.185, 6.6.154, 6.12.106, 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80735: ovpn dereferenced socket data it did not own

The in-kernel OpenVPN data channel stores its own state in the socket's sk_user_data field. Other subsystems use the same field for their own purposes. BPF SOCKMAP, for example, sets sk_user_data without setting the encapsulation type that ovpn uses to recognise its own sockets. So ovpn could dereference a pointer belonging to another subsystem, which gives out-of-bounds reads. The fix checks the encapsulation type before the dereference.

This is narrow but relevant on gateways that terminate VPN tunnels and also run BPF programs on sockets, which is a common combination on modern edge routers. The ovpn driver was merged in 6.16, so the older LTS branches do not contain this code at all. The affected file is drivers/net/ovpn/socket.c, so the gate is CONFIG_OVPN. Fixed in 6.18.45 and 7.1.9. See the CVE record.

Cloud and datacenter

The highest priority here is the NVMe-over-TCP target, because the input arrives from the network before authentication. The guest-to-host records come next, then the local memory-corruption records that matter on shared hosts.

CVE-2026-80789: NVMe-over-TCP target allocated buffers from an unbounded wire value

The target reads the 32-bit SGL length sent by the initiator. For the in-capsule descriptor type it checks that length against the configured inline data size. For every other descriptor type, including the transport data-block descriptor that a real initiator uses for out-of-capsule writes, the check is skipped and the value goes straight into the scatterlist allocator. The value is host-controlled and unbounded up to 4 GiB, and no other layer inspects it. The fix bounds the length before the allocation.

Treat this as the first item on any host that exports NVMe-over-TCP namespaces, because the trigger is a single command from anything that can open a TCP connection to the target port. The companion record CVE-2026-80788 covers the same code path from the other side: an oversized SGL made the page allocator hit a warning that a remote initiator could trigger at will, and that warning is now removed. The affected file is drivers/nvme/target/tcp.c, so the gate is CONFIG_NVME_TARGET_TCP. Fixed in 5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.106, 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80891: KVM on s390 pinned guest pages without validating the interrupt vectors

For PCI passthrough on s390, the host pins guest pages that hold the adapter interrupt bit vector and the summary bit indicator. The size of the bit vector is derived from values the guest supplies. Neither the size nor the alignment was validated, so a bit vector spanning more than one page, or a summary address that is not 8-byte aligned, could be accepted and pinned. The fix rejects both cases.

This crosses the guest-to-host boundary, which is why it belongs at the top of the list on any s390 host that passes PCI functions through to guests. The affected file is arch/s390/kvm/pci.c, so the gate is CONFIG_KVM on s390 together with zPCI passthrough enabled. Fixed in 6.1.183, 6.6.151, 6.12.103, 6.18.44 and 7.1.8. See the CVE record.

CVE-2026-80853: KVM SEV used a partial page as a firmware command buffer

When KVM encrypts or decrypts guest memory through a temporary buffer, the page holding that buffer is handed to SEV firmware for the duration of the command. On an SNP-enabled host, a page assigned to firmware must be wholly owned by KVM, because other kernel code sharing the same page could be allocated and accessed while the transfer of ownership is in effect. The buffer was smaller than a page, so the rest of the page was not KVM's. The fix allocates a full 4 KiB page.

This is the one record in this advisory that affects a single branch. It is fixed in 7.2.3, and no other stable branch is named as affected. It matters for confidential-computing hosts that run SEV or SEV-ES guests on SNP-capable hardware. The affected file is arch/x86/kvm/svm/sev.c, so the gate is CONFIG_KVM_AMD_SEV. See the CVE record.

CVE-2026-80758: use-after-free in the futex private hash

The futex code drops its reference to the private hash and then reads a field out of that same structure. Dropping the reference re-enables preemption. If that drop released the last reference and the task is then preempted, another task can switch to the replacement hash and free the old one after a grace period. When the first task resumes, it reads from freed memory. KASAN reports a use-after-free read in a freed 512-byte allocation. The fix loads the field while the reference is still held.

Futex code is reachable by any unprivileged process, and it is built on every normal configuration; turning it off requires an expert-mode kernel config. That makes this the widest-reaching local record of the week, and it is the one to prioritise on multi-tenant hosts and container fleets. Four more futex records land in the same week: CVE-2026-80775 is a race on the initial private-hash allocation and CVE-2026-80776 is a race during the private-hash resize, and CVE-2026-80777 and CVE-2026-80778 fix ownership handling across exec() and across address spaces. The affected file is kernel/futex/core.c. Fixed in 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80810: io_uring computed a folio size with a 32-bit shift

When filling the bio vector for a registered buffer, io_uring computed the folio size as 1 << imu->folio_shift using a plain int for the 1. The shift count comes from the folio backing the buffer and can be 32 or more on a 64-bit kernel. Shifting a 32-bit value that far is undefined behaviour, and on x86 and arm64 the processor takes the count modulo 32, so a shift of 34 produces 4 instead of 16 GiB. The size estimate and the fill loop then disagree about how many segments are needed. The fix uses an unsigned long, as the rest of the file already does.

The precondition is a registered buffer backed by a very large folio, which in practice means a host configured for 1 GiB pages or larger. That is a deliberate configuration, not a default, so most systems are not exposed. On hosts that do use huge folios with io_uring, an unprivileged process can reach it. A second io_uring record this week, CVE-2026-80811, fixes an iovec leak in the io_uring command path. The affected file is io_uring/rsrc.c, so the gate is CONFIG_IO_URING. Fixed in 6.18.47, 7.1.11 and 7.2.1. See the CVE record.

CVE-2026-80850: use-after-free of TCP-AO state on connect

TCP Authentication Option protects long-lived TCP sessions, and it is most often used on BGP peerings. On connect, the socket is added to the lookup hash before the AO key state is initialised. The connect path first checks that a key matches the peer and the bound device's VRF membership, then resolves the VRF again later and removes keys that do not match. The socket lock does not stop the device from being detached from its VRF in between. If that happens, the first check passes, the second observes a different VRF and removes the only key, and the no-key path then frees the AO state on a socket that is already visible in the hash. The fix keeps the two views consistent.

The trigger requires a VRF change during connect, so this is a race rather than something a remote peer can drive on its own. It is listed here because the affected deployments are network devices and routing hosts that use both VRFs and TCP-AO. The affected file is net/ipv4/tcp_ao.c, so the gate is CONFIG_TCP_AO. Fixed in 6.12.108, 6.18.49, 7.1.13 and 7.2.3. See the CVE record.

CVE-2026-80852: out-of-bounds write in the kTLS transmit offload path

The kTLS device path checks whether an open record still has room for another fragment only at the bottom of its loop, and the MSG_MORE early exit skips that check. The record then survives into the next system call with the fragment count it already had, and the append function does not check either. With transmit zero-copy enabled, repeated splice() calls with SPLICE_F_MORE each add a fragment that cannot be merged, and the fragment count grows past the end of the fixed-size fragment array in the record structure. That is an out-of-bounds write. The fix adds the missing checks.

The precondition is real hardware TLS transmit offload. The record notes it was found with a network device simulator, because the code path is otherwise only reachable on a NIC that implements the offload. So this matters on datacenter hosts with kTLS offload enabled on the NIC, and nowhere else. The affected file is net/tls/tls_device.c, so the gate is CONFIG_TLS_DEVICE. Fixed in 6.1.187, 6.6.156, 6.12.108, 6.18.49, 7.1.13 and 7.2.3. See the CVE record.

Medical devices

Several of this week's records are worth reviewing for connected clinical equipment, and they fall into three groups.

Wireless and short-range links. CVE-2026-80762 matters for wearables, patient monitors and any device that suspends and wakes on a Bluetooth link, and the other six Bluetooth records this week are in the same connection-lifetime area. CVE-2026-80795 and CVE-2026-80799 matter for equipment that reads NFC tags, which includes patient wristband readers and consumable authentication on infusion and dialysis equipment.
Network protocols. Devices that carry DICOM, HL7 or FHIR over IP should review CVE-2026-80850 if they use TCP Authentication Option, and should note that CVE-2026-74752 in SCTP, carried over from last week, is still unfixed on every LTS branch below 7.1. Devices that reach the network through a USB cellular modem should review CVE-2026-80827.
Bedside peripherals. CVE-2026-80781 in the HID core, and the 13 other HID records this week, apply to any device with an attached keyboard, barcode scanner, pointing device or foot pedal. Check whether your image builds CONFIG_DEBUG_FS, because that decides whether this particular record is reachable at all.

Patching a medical device is not the same as patching a server. The update has to pass validation and regulatory revalidation, under the US FDA postmarket cybersecurity guidance, the EU Medical Device Regulation (MDR) and IEC 62304. So the action is to plan the stable kernel update through the manufacturer's change-control process, and not to apply it outside that process.

How to check which Linux kernel CVEs apply to you

There are three questions.

First, version. Compare the running kernel version with the table above. Because this week's targets are the newest release on every branch, the check is simple: if you are not on the current release for your branch, you are behind. Unlike last week, the branch target is the whole answer this time, because no record leaves a branch affected and unfixed.

Second, configuration. Check your kernel config for the feature behind each record. If the vulnerable code is not built into the kernel and is not available as a loadable module, the record is generally not reachable through that feature. On a running system with config access enabled, one command covers the most widely built of them.

raghu@techveda.org:~$ zcat /proc/config.gz | grep -E '^(# )?CONFIG_(BT|NFC|HID|IO_URING|TLS_DEVICE|USB_SERIAL_OPTION)[ =]'
CONFIG_BT=m
CONFIG_NFC=m
CONFIG_HID=y
CONFIG_IO_URING=y
# CONFIG_TLS_DEVICE is not set
CONFIG_USB_SERIAL_OPTION=m

The pattern is anchored on purpose. A plain grep CONFIG_BT would also match CONFIG_BTRFS_FS and every CONFIG_BT_* sub-option, which makes the output hard to read. The other symbols used in this advisory are CONFIG_MT7925U, CONFIG_CAN_ISOTP, CONFIG_DRM_DISPLAY_HDMI_STATE_HELPER, CONFIG_NFC_NCI, CONFIG_DEBUG_FS, CONFIG_OVPN, CONFIG_NVME_TARGET_TCP, CONFIG_KVM, CONFIG_KVM_AMD_SEV and CONFIG_TCP_AO.

Read =m differently from =y. A symbol set to m means the code is present on the system and can be loaded, so it still counts as reachable unless your module-loading policy prevents it. If your system has no /proc/config.gz, use the config file from your build tree or the matching file under /boot. One record in this advisory, CVE-2026-80758 in futex, has no practical config gate at all, because futex support is built on every normal configuration.

Third, reachability, which sets the order of work. The records describe code paths rather than attacker models, so the ordering below is our reading of reachability and not a statement from the kernel CVE team.

Remote and over-the-air paths come first. On a storage host, that means CVE-2026-80789 in the NVMe-over-TCP target, because a single command from any client that can reach the port triggers it. On a device with a radio, that means the NFC records and the Bluetooth records. Local unprivileged memory corruption comes second, led by CVE-2026-80758 in futex, which is reachable by any process on almost any configuration. Guest-to-host records come third and are first in priority on shared hosts: CVE-2026-80891 on s390 and CVE-2026-80853 on SEV hardware. Records that need a specific configuration or specific hardware come last, which is where CVE-2026-80852, CVE-2026-80810 and CVE-2026-80749 sit.

Key takeaways

Update to the target release for your branch: 5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.108, 6.18.49, 7.1.13 or 7.2.3. Each target is the newest release of its branch.
The 7.1 branch reached end of life with 7.1.13 on 2 September 2026. Install 7.1.13, then plan a move to 7.2 or to a longterm branch such as 6.18, because no further 7.1 release will come.
Unlike last week, the branch update clears everything published in this window. No record this week marks a branch as affected without naming a fix for it.
Three USB records set the target on all eight branches: CVE-2026-80824, CVE-2026-80827 and CVE-2026-80830.
Five older items are still open on the older LTS branches: CVE-2026-74752, CVE-2026-80551, CVE-2026-74743, CVE-2026-80635 and CVE-2026-74582. Nothing this week changes them, so keep tracking them separately.
On a storage host, schedule CVE-2026-80789 first. The NVMe-over-TCP target allocated buffers from an unbounded value sent by the initiator.
On a multi-tenant or container host, schedule CVE-2026-80758 first. Futex code is reachable by any unprivileged process and is built on every normal configuration.
On a device with a radio, the NFC group (eleven records this week) and the Bluetooth group (seven records) are the ones to take as a unit rather than as single patches.
On a vendor or BSP kernel, ask the vendor to confirm the fixes are in their tree rather than comparing version strings.
None of the records notes known exploitation, and no public exploit code was found for any of them at the time of writing. That is a point-in-time check, not a guarantee.

Frequently asked questions

What is the one thing I should do?
Update to the target release for your branch: 5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.108, 6.18.49, 7.1.13 or 7.2.3. Each of those is the newest release of its branch, so on an upstream kernel you just install the current release. If you run a vendor or BSP kernel, ask your vendor to confirm the fixes are in their tree instead, because a vendor version string will not compare cleanly with those numbers.

I run 7.1. What does its end of life mean for me?
7.1.13, released on 2 September 2026, is the final release of the 7.1 branch. It contains the fixes for every record in this advisory, so installing it is still the right action today. But no 7.1.14 will follow, so from now on kernel CVEs affecting code that 7.1 contains will stay unfixed on that branch. Install 7.1.13, then plan a move to 7.2, which is the current stable series, or to a longterm branch such as 6.18 if you would rather change kernel version rarely. There is no time pressure this week, because 7.1.13 is fully patched.

Is 188 CVEs in one week a lot?
No, it is close to a normal week for this project. Last week was 227, and that was unusual because a full stable cycle landed on a single day and all the records were published together. This week the count comes from ordinary weekly stable releases. The IDs form one continuous block, CVE-2026-80726 to CVE-2026-80913.

Are any of these a 0-day?
No. All 188 were published with fixes already in stable, and this week every record names a fixed version for every branch it marks as affected. None of the records notes known exploitation, and no public exploit code was found for any of them at the time of writing, though that is a point-in-time check rather than a guarantee. The action is to schedule the stable update through your normal process.

I already applied last week's targets. Am I covered?
No. Last week's targets were 5.10.268, 5.15.219, 6.1.186, 6.6.155, 6.12.107, 6.18.48, 7.1.12 and 7.2.2. Every branch has moved up exactly one point release since then, so you need this week's targets as well. Three USB records, CVE-2026-80824, CVE-2026-80827 and CVE-2026-80830, are the reason the target moved on every branch.

Which one should I schedule first?
It depends on what the machine does. On a host that exports NVMe-over-TCP namespaces, CVE-2026-80789, because the input arrives from the network before authentication. On a multi-tenant or container host, CVE-2026-80758 in futex, because any unprivileged process can reach it. On an s390 host with PCI passthrough, CVE-2026-80891. On a device with an NFC or Bluetooth radio, the NFC group and the Bluetooth group. On a gateway with a USB cellular modem, CVE-2026-80827.

We do not build NFC, Bluetooth or NVMe-over-TCP. Do these affect us?
Each bug is gated by a kernel config option, and the ones used in this advisory are CONFIG_MT7925U, CONFIG_BT, CONFIG_CAN_ISOTP, CONFIG_DRM_DISPLAY_HDMI_STATE_HELPER, CONFIG_USB_SERIAL_OPTION, CONFIG_NFC_NCI, CONFIG_NFC, CONFIG_HID with CONFIG_DEBUG_FS, CONFIG_OVPN, CONFIG_NVME_TARGET_TCP, CONFIG_KVM, CONFIG_KVM_AMD_SEV, CONFIG_IO_URING, CONFIG_TCP_AO and CONFIG_TLS_DEVICE. If the vulnerable code is not built into the kernel and is not available as a loadable module, the record is generally not reachable through that feature. Read a symbol set to m as still present and loadable rather than absent. One record is an exception: CVE-2026-80758 in futex has no practical config gate, because futex support is built on every normal configuration.

Why did only some records get their own heading?
188 records is too many to explain one by one, so this advisory explains the ones that are reachable over the air, reachable by an unprivileged local process, or reachable across the guest-to-host boundary, plus a few that are tied to a specific device class. Every record in the window is fixed by the branch target in the table, so the ones without a heading are covered by the same single update.

DEV Community