Linux Kernel CVEs: What to Patch by Device (23 – 29 Aug 2026)

Last week this series covered six CVEs. This week it is 227. The jump is not a sudden collapse in kernel quality. The CVE IDs show what happened: 21 sit in the CVE-2026-747xx block and 206 in the CVE-2026-805xx to 807xx block, and on 28 August the kernel project cut a new point release on every active branch at once. The records for everything in those releases were published together.

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. Where this advisory quotes a CVSS score, that score is the kernel CNA’s own, carried as a secondary metric; NVD has not finished analysing this batch and publishes no base score of its own for most of it, so other vendors and enrichment databases may publish different figures later. Prioritise by reachability and deployment context rather than by CVSS alone. This advisory gives the version to install first, then explains which CVEs matter for mobile and automotive, embedded and IoT, cloud and datacenter, and medical devices. Each CVE below has its own heading so you can link straight to it.

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

Run uname -r to see your current kernel version. Compare it with the target for your branch in the table below. If your version is lower than the target, update to the target release or newer.

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

In that example the running kernel is 6.6.152, which is below the 6.6 target of 6.6.155, so the system needs an update.

Every target above is a release that already exists, so nothing here waits on a future stable release. All eight stable targets are in fact the newest release of their branch, and all eight were cut on 28 August, so on an upstream kernel the check is simple: if you are not on the current release for your branch, you are behind. One record, CVE-2026-80590, sets the target on all eight branches by itself. It fixes stale GSO state left on IPv4 fragments before reassembly, it is fixed only in stable and names no mainline entry, and it is the practical reason this week’s numbers are what they are. Two other records also name no mainline fix: CVE-2026-80724 and CVE-2026-74753.

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 no longer appear on the kernel.org active release list.

Four records the branch update does not clear

This is the part to read before you close the ticket. Four of the records discussed below mark a branch as affected and name no fixed version for it. Installing the table target does not remediate them on those branches.

• CVE-2026-74752 (SCTP, CVSS 9.8) — introduced in 2.6.24, fixed only in 7.1.10 and mainline 7.2. No fix named for 5.10, 5.15, 6.1, 6.6, 6.12 or 6.18. This is the widest gap this week.
• CVE-2026-80551 (s390 vfio-ccw, CVSS 9.3) — introduced in 5.3, fixed in 6.6.154 and later. No fix named for 5.10, 5.15 or 6.1.
• CVE-2026-74743 (macvlan, CVSS 9.8) — introduced in 2.6.23, fixed in 6.1.184 and later. No fix named for 5.10 or 5.15.
• CVE-2026-80635 (wcn36xx Wi-Fi) — introduced in 4.7, fixed in 6.1.178 and later. No fix named for 5.10 or 5.15.

Read those four records directly and ask your vendor, rather than assuming the branch update covers them. Note also that last week’s CVE-2026-74582 is still not fixed on 5.10, 5.15 or 6.1, and nothing in this week’s 227 records changes that. If you ship one of the older LTS branches, you now have five open items to track separately from the branch bump.

One comparison is worth making. Last week’s targets were 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9 and mainline 7.2. Every branch moved up exactly three point releases on 28 August, so a system that was current after last week’s advisory is behind this week.

We read all sixteen of the records that get their own heading below directly against the CVE Program record, and confirmed each one’s fixed versions, affected-from version and score. For the remaining records we relied on the published fixed-version data without opening each one. That is why the table is trustworthy as a branch target and why the four gaps above are listed explicitly: they came out of reading the records, not out of the version arithmetic.

If you run a vendor or BSP kernel, the version string will not compare cleanly with the table. A kernel that reports 5.10.110-rk3588 is based on 5.10.110, and it will not become 5.10.268 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.

Updating to a verified fixed kernel or vendor backport is the preferred remediation. Until that is possible, reduce exposure by disabling unused features, restricting the relevant privileges, and documenting the residual risk through your product security process.

Mobile and automotive

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

CVE-2026-80707: CAN J1939 receive buffer was not zeroed

J1939 is the transport protocol used on heavy vehicles, agricultural equipment and other CAN-based machinery. When a new receive session was created, the session buffer was allocated but not zeroed, so any part the peer never wrote kept whatever the kernel had left in that memory. The fix zeroes the buffer in j1939_session_fresh_new(). The record notes a possible performance cost only for maximum-sized ETP buffers, around 65K.

The record states the residual-data problem and the fix; it does not describe a readback path, so treat “a peer could read stale kernel memory back” as our inference from the mechanism rather than a claim the record makes. It affects 4.19 and later. Gate CONFIG_CAN_J1939. Fixed in 5.10.265, 5.15.216, 6.1.183, 6.6.151, 6.12.103, 6.18.44, 7.1.8 and mainline 7.2. See the CVE record.

CVE-2026-74737: TI AM65 Ethernet used hardware-reserved bits as part of a port index

The driver takes the MAC port ID from the 16-bit Source Tag in the receive descriptor metadata. Only the lower 8 bits carry the port ID; the upper 8 bits are hardware-reserved and hold an arbitrary value, and the driver was using the whole field. The record reports sporadic kernel crashes from the resulting out-of-bounds access. The fix masks the tag to its lower 8 bits.

Read the scoring carefully here. The record carries CVSS 9.8 with a network attack vector, but its own description attributes the invalid index to hardware-reserved bits rather than to attacker-chosen packet content, so this reads as a reliability defect with a high score rather than a demonstrated remote attack. The TI AM65 and Sitara families are, in our experience, common in industrial and automotive gateways; the record does not say so. Gate CONFIG_TI_K3_AM65_CPSW_NUSS. Fixed on all seven stable branches that name a fix — 5.10.266, 5.15.217, 6.1.184, 6.6.153, 6.12.105, 6.18.46, 7.1.10 — plus mainline 7.2. See the CVE record.

CVE-2026-80722: mac80211 partially validated an S1G TWT setup frame

Target Wake Time lets a station and an access point agree when the station will wake. ieee80211_process_rx_twt_action() only partially validates a received S1G TWT setup frame before queueing it, so an individual agreement can reach ieee80211_s1g_rx_twt_setup() with twt->length too short for the full parameters structure. The individual path then hands that short block to drv_add_twt_setup(), and both the tracepoint and the driver callback read the complete parameters block. Broadcast agreements are unaffected, because they are rejected locally after touching only the request type.

Note the S1G qualifier: this is the sub-1GHz path, not ordinary 2.4 or 5GHz operation. The code sits in the generic 802.11 stack rather than a vendor driver, and the affected file has no config option of its own, so it is present wherever mac80211 is built. The fix validates each individual agreement before driver setup. It affects 5.15 and later. Gate CONFIG_MAC80211. Fixed in 5.15.216, 6.1.183, 6.6.151, 6.12.103, 6.18.44, 7.1.8 and mainline 7.2. See the CVE record.

CVE-2026-80721: Bluetooth ISO could leave a dangling connection pointer

After iso_conn_del(), ISO sockets must not dereference the hcon connection object any more. Clearing iso_conn::hcon depended on iso_conn_del() happening to drop the last reference to the iso_conn. The fix clears conn->hcon explicitly so the pointer cannot be left dangling regardless of who holds the last reference.

Isochronous channels carry LE Audio. This is one of four Bluetooth records this week; the others are CVE-2026-80692 (the connection was not held across the hci_connect_acl and hci_connect_le callbacks), CVE-2026-80683 (the SCO socket lacked its own connection reference) and CVE-2026-80666 (a race in the SCO socket timeout). All four concern connection-object lifetime and references. If you ship Bluetooth, apply the branch update rather than picking single patches. It affects 6.0 and later. Gate CONFIG_BT together with CONFIG_BT_LE, because the isochronous code is built only when LE support is enabled. Fixed in 6.18.44, 7.1.8 and mainline 7.2. See the CVE record.

Embedded and IoT

Routers, gateways and single-board computers are affected through the firewall offload path, the connection tracking helpers, a Wi-Fi driver and the device tree.

CVE-2026-74746: use-after-free in the netfilter flow table

The flow table is the software offload path that lets established connections skip the full ruleset. Garbage collection could free a flow entry while flow_offload_add() was still inserting it into the hash table. KASAN reports both slab-use-after-free reads and writes. The fix publishes the GC-visible tuple last, so the entry is not reachable by GC until insertion is complete.

This is the highest-priority record for anyone running a Linux gateway or router: the trigger is ordinary forwarded traffic once flow offload is enabled, and the consequence is memory corruption in a core networking path. It carries CVSS 9.8 and affects 5.13 and later. Gate CONFIG_NF_FLOW_TABLE. Fixed on all seven stable branches that name a fix — 5.10.266, 5.15.217, 6.1.184, 6.6.153, 6.12.105, 6.18.46, 7.1.10 — plus mainline 7.2. See the CVE record.

CVE-2026-80603: off-by-one read in the netfilter IRC helper corrupts DCC expectations

The IRC connection tracking helper parses DCC messages so the firewall can open the matching data connection. parse_dcc() read one byte past the region filled by skb_header_pointer(). The record is explicit that this is not currently an out-of-bounds read: the buffer is allocated one byte larger than the cap, so the stray read does not fault. The consequence is that a stale or uninitialised byte can be consumed by simple_strtoul and produce a wrong DCC IP or port in the conntrack expectation. The record calls the spare allocation byte a fragile guard that would become a real out-of-bounds read if the cap or allocation size changed.

So the practical risk is a firewall induced to open the wrong data connection, not memory corruption. This one is also easy to remove rather than patch: the IRC helper is optional and many products build it without using it. It affects 2.6.12 and later. Gate CONFIG_NF_CONNTRACK_IRC. Fixed in 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5 and mainline 7.2. See the CVE record.

CVE-2026-80635: out-of-bounds read from a short firmware response in wcn36xx

The driver parses a trigger block-acknowledgement response from the Wi-Fi firmware. A response shorter than expected was not rejected, so the parser reads a 22-byte structure at an offset past the end of the message. The input is the firmware response, not network traffic. The fix checks the response length before the read.

It affects 4.7 and later. The record names no fix for 5.10 or 5.15, so those branches are affected and unfixed upstream. Gate CONFIG_WCN36XX. Fixed in 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5 and mainline 7.2. See the CVE record.

CVE-2026-80723: out-of-bounds write when the boot device tree declares too many reserved regions

On boot, fdt_scan_reserved_mem() saves each dynamically-placed reserved-memory subnode into a local array of fixed size. The region count was not checked against that size, so a device tree declaring too many drives a write past the end of the array. The fix bounds the count.

This is an embedded-specific bug in a way most kernel CVEs are not. The count comes from whatever flattened device tree the platform hands the kernel at boot, so if your boot chain composes the device tree from a base tree plus overlays before handing it over, or lets a carrier board contribute reserved-memory nodes, the region count is not something you control at build time. Overlays applied later at runtime do not go through this path. It affects 3.15 and later. Gate CONFIG_OF_RESERVED_MEM. Fixed in 6.12.103, 6.18.44, 7.1.8 and mainline 7.2. See the CVE record.

Cloud and datacenter

The guest-to-host records are the highest priority on shared hosts. Container networking, MPTCP, Ceph, SCTP and io_uring follow.

CVE-2026-80551: s390 vfio-ccw double-fetch of the first IDAW

When a guest submits a channel program, the host reads the first indirect address word to work out how large a buffer it needs, then reads it again while filling that buffer. Nothing guaranteed the value was the same both times. A guest that changes it in between makes the host size one buffer and fill another. The fix keeps the first IDAW constant across both uses.

This is a double-fetch across the guest-to-host boundary, and it carries CVSS 9.3. It is one of nine vfio-ccw records this week, CVE-2026-80547 through CVE-2026-80555, which together rework locking and object lifetime in the driver. All nine carry a CVSS vector with scope marked as changed, which is the standard way of recording that a security boundary is crossed. CVE-2026-80554, unbounded recursion while processing channel programs and the CCWs inside them, is the other CRITICAL of the group at 9.3. Treat the nine as one unit and take the branch update. It affects 5.3 and later. The record names no fix for 5.10, 5.15 or 6.1. Gate CONFIG_VFIO_CCW. Fixed in 6.6.154, 6.12.105, 6.18.46, 7.1.10 and mainline 7.2. See the CVE record.

CVE-2026-80590: stale GSO state left on IPv4 fragments before reassembly

IPv4 fragment reassembly did not strip GSO state from the incoming fragments, so reassembled packets carried segmentation offload metadata that no longer described them. The fix strips that state before reassembly.

This record carries no CVSS score and no dramatic description, but it is the one that matters most to the table above: it is fixed on every stable branch and names no mainline entry, and its fixed versions are exactly this week’s eight targets. If you want to know why the minimum safe version moved on your branch, this is the record. It is fixed in 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. See the CVE record.

CVE-2026-74743: macvlan did not inherit headroom from the lower device

A macvlan device did not inherit the headroom and tailroom requirements of the device underneath it, so the transmit path can underflow the headroom it reserved in the socket buffer, which KASAN reports as a slab use-after-free. The fix inherits needed_headroom and needed_tailroom from the lower device.

The precondition decides whether you are affected at all: the record names macsec, IPsec, WireGuard, tunnels, and veth with rx headroom as lower devices that require extra space. A macvlan over a plain physical NIC is not in scope. CVE-2026-74744 is the identical fix in ipvlan and carries the same 9.8 score, with gate CONFIG_IPVLAN. Both matter on container hosts, where macvlan and ipvlan are the usual ways to give a container its own MAC address on the physical network. It affects 2.6.23 and later. The record names no fix for 5.10 or 5.15. Gate CONFIG_MACVLAN. Fixed in 6.1.184, 6.6.153, 6.12.105, 6.18.46, 7.1.10 and mainline 7.2. See the CVE record.

CVE-2026-74752: SCTP restored AUTH fields straight from peer-controlled cookie bytes

When cookie authentication is disabled, a COOKIE_ECHO restores fixed-size AUTH fields directly from peer-controlled cookie bytes with no validation. A forged RANDOM length gives out-of-bounds reads while the key vector is built, and a forged HMAC identifier caused a 32-byte write past a zero-length AUTH chunk — which the record describes as a primitive for a local privilege escalation chain. The fix validates the cookie AUTH state before use.

Two things to keep straight. The precondition is that cookie authentication is disabled, and the escalation the record claims is local, not remote, even though the record scores it CVSS 9.8 with no privileges required. CVE-2026-80717 is a second SCTP record this week, a missing length check on the Adaptation Indication parameter. SCTP carries signalling in telecom stacks and, in our experience, in some clinical and industrial equipment. It affects 2.6.24 and later. This is the widest gap this week: the record names no fix for 5.10, 5.15, 6.1, 6.6, 6.12 or 6.18. Gate CONFIG_IP_SCTP. Fixed in 7.1.10 and mainline 7.2 only. See the CVE record.

CVE-2026-80586: MPTCP processed a second suboption against leftover state

A remote peer can send a malformed DSS option with a wrong size followed by another DSS, or by MPC plus data, in the same packet. The malformed suboption is ignored, but it leaves some fields already written, so the second suboption is processed against leftover state. The record names inconsistency and reads of uninitialised data as the outcomes. The fix resets the DSS fields when the size is unexpected.

This is one of four MPTCP records this week. CVE-2026-80587, also 9.8, lets a peer combine incoming suboptions that should not be combined. CVE-2026-80585, 9.4, marks subflows as MPTFO when they carry no SYN data. CVE-2026-80588 leaks forward-allocated memory on receive-path errors. It affects 5.11 and later. Gate CONFIG_MPTCP. Fixed in 5.10.266, 5.15.217, 6.1.184, 6.6.153, 6.12.105, 6.18.46, 7.1.10 and mainline 7.2. See the CVE record.

CVE-2026-80557: out-of-bounds read decoding a Ceph watcher list

The Ceph client decodes structures sent by an OSD. The watcher list decoder did not bound-check the data before reading it. The fix adds the missing bounds check.

The record gives an unusually explicit attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, with no privileges beyond OSD session establishment. Two more libceph records this week are the same class — CVE-2026-80558, unvalidated OSD indices taken from the osdmap, and CVE-2026-80561, several unchecked decodes in the lock client — and all three carry 9.8. There is also CVE-2026-80528 in the Ceph filesystem client, where under memory pressure JBD2 misreads Ceph’s current->journal_info as a journal handle; that chain needs another mounted ext4 filesystem to be in play. It affects 3.10 and later. Gate CONFIG_CEPH_LIB. Fixed in 5.10.267, 5.15.218, 6.1.185, 6.6.154, 6.12.106, 6.18.47, 7.1.10 and mainline 7.2. See the CVE record.

CVE-2026-80713: io_uring dropped per-task restrictions on exec

A task can install io_uring restrictions that apply to every ring it creates. Once installed they should survive an exec. For a task that had used io_uring, the exec cancellation path called __io_uring_free(), which freed the per-task restriction along with the task context, so any ring created after the exec came up unrestricted. The fix preserves the restrictions across exec.

This is not memory corruption. It is a confinement bug: a limit that was applied is silently no longer applied to rings created after an exec. Anyone relying on io_uring restrictions as part of a sandbox should treat this as a correctness bug in that sandbox. It affects 5.10 and later. Gate CONFIG_IO_URING. Fixed in 7.1.8 and mainline 7.2. See the CVE record.

Medical devices

Several of this week’s records are worth reviewing for connected clinical equipment. They fall into three groups.

• Wireless. CVE-2026-80721 and the three other Bluetooth records — CVE-2026-80692, CVE-2026-80683, CVE-2026-80666 — matter for wearables, patient monitors and hearing devices, and the LE Audio path specifically. CVE-2026-80722 in the generic 802.11 stack matters for equipment on hospital wireless networks, but only where the sub-1GHz S1G path is in use.
• Network protocols. Devices that carry DICOM, HL7 or FHIR over IP should review the two SCTP records, CVE-2026-74752 and CVE-2026-80717, and note that the first is unfixed on every LTS branch below 7.1. A device built on a TI AM65 or Sitara part should also review CVE-2026-74737.
• Removable media. This week carries a large group of filesystem records driven by a crafted image. The ones to read are CVE-2026-80672, CVE-2026-80673 and CVE-2026-80674 in NTFS, CVE-2026-80598 in NTFS3, CVE-2026-80631 in btrfs, CVE-2026-80656 in HFS+ and CVE-2026-80591 in f2fs. Any device that auto-mounts a USB stick to import or export patient data should review that group.

Patching a medical device is not the same as patching a server. The update has to pass validation and regulatory revalidation. The rules that apply are 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. Do not apply it outside that process.

How to check which Linux kernel CVEs apply to you

There are three questions.

First, version. Run uname -r and compare 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. Then read the four-gap list, because on 5.10, 5.15 and 6.1 the branch target is not the whole answer.

Second, configuration. Check your kernel config for the feature behind each CVE. If the vulnerable code is not built into the kernel or available as a loadable module, the CVE is generally not reachable through that feature. Confirm dependencies, module-loading policy and vendor configuration before you close the finding. 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_(MAC80211|BT|NF_FLOW_TABLE|IP_SCTP|MACVLAN|IO_URING)[ =]'
CONFIG_MAC80211=m
CONFIG_BT=m
CONFIG_NF_FLOW_TABLE=m
CONFIG_IP_SCTP=m
CONFIG_MACVLAN=m
CONFIG_IO_URING=y

The pattern is anchored on purpose. A plain grep CONFIG_BT would also match CONFIG_BTRFS_FS and every CONFIG_BT_* sub-option, which buries the answer. The other symbols worth checking are CONFIG_CAN_J1939, CONFIG_TI_K3_AM65_CPSW_NUSS, CONFIG_BT_LE, CONFIG_NF_CONNTRACK_IRC, CONFIG_WCN36XX, CONFIG_OF_RESERVED_MEM, CONFIG_VFIO_CCW, CONFIG_IPVLAN, CONFIG_MPTCP and CONFIG_CEPH_LIB.

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.

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

On a host that runs untrusted guests, the s390 vfio-ccw group comes first, led by CVE-2026-80551 and CVE-2026-80554, because they cross the guest-to-host boundary. On a gateway or router, CVE-2026-74746 comes first, because forwarded traffic reaches it and the result is memory corruption. On a storage client, the libceph group comes first. On a device with a radio or a bus that faces the outside world, CVE-2026-80722, the Bluetooth group and CVE-2026-80707 come first. Remote network protocol records follow, led by the MPTCP group. Local confinement issues such as CVE-2026-80713 come next, and records that need a specific configuration, a crafted filesystem image or physical media access come last. Cutting across all of that: if you run 5.10, 5.15 or 6.1, the four unfixed records above outrank everything on this list, because no update clears them.

Key takeaways

• Update to the target release for your branch: 5.10.268, 5.15.219, 6.1.186, 6.6.155, 6.12.107, 6.18.48, 7.1.12, 7.2.2, or mainline 7.2. All eight stable targets are the newest release of their branch and all eight were cut on 28 August, so on an upstream kernel the action is simply to install the current release.
• The branch update does not clear everything. CVE-2026-74752, CVE-2026-80551, CVE-2026-74743 and CVE-2026-80635 each mark a branch as affected and name no fix for it. On 5.10 and 5.15 all four apply; on 6.1 two apply; on 6.6, 6.12 and 6.18 one applies. Track them separately.
• Last week’s CVE-2026-74582 is also still unfixed on 5.10, 5.15 and 6.1, so older LTS branches now carry five open items.
• On a vendor or BSP kernel, ask the vendor to confirm the fixes are in their tree rather than comparing version strings.
• 227 CVEs is a large number, but the driver is a full stable cycle landing on one day, not a sudden collapse in kernel quality.
• There is a new 7.2 stable branch. Mainline 7.2 shipped on 16 August and now has point releases; the current one is 7.2.2.
• On hosts running untrusted guests, treat the nine s390 vfio-ccw records as one unit and take the branch update rather than cherry-picking.
• On gateways and routers, CVE-2026-74746 in the netfilter flow table is the one to schedule first. On container hosts using macvlan or ipvlan over macsec, IPsec, WireGuard, a tunnel or veth, apply CVE-2026-74743 and CVE-2026-74744.
• 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. Use your kernel config to remove the CVEs that do not apply, then test the update on your own hardware.

Frequently asked questions

What is the one thing I should do?
Update to the target release for your branch: 5.10.268, 5.15.219, 6.1.186, 6.6.155, 6.12.107, 6.18.48, 7.1.12, 7.2.2, or mainline 7.2. All eight stable targets are the newest release of their branch, so on an upstream kernel you just install the current release. Then read the four-gap list, because four records name no fix for branches they mark as affected. 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.

Why are there 227 CVEs this week when last week had six?
A full stable cycle landed on 28 August. The kernel project cut a new point release on every active branch on the same day, and the CVE records for everything in those releases were published together. The IDs show it: 21 sit in the CVE-2026-747xx block and 206 in the CVE-2026-805xx to 807xx block. The count reflects a release cadence, not a sudden collapse in kernel quality.

Are any of these a 0-day?
No. All 227 were published with fixes already in stable, though four of them are not fixed on every branch they affect. 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.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9 and mainline 7.2. Every branch moved up exactly three point releases on 28 August, so you need this week’s targets as well. Separately, four records this week and one from last week name no fix for branches they mark as affected, so on 5.10, 5.15 and 6.1 the branch update is not the whole answer.

Which one should I schedule first?
It depends on what the machine does. On a host running untrusted guests, the s390 vfio-ccw group, led by CVE-2026-80551 and CVE-2026-80554. On a gateway or router, CVE-2026-74746 in the netfilter flow table. On a storage client, the libceph group. On a device with a radio or a CAN bus, CVE-2026-80722, the Bluetooth group and CVE-2026-80707. If you run 5.10, 5.15 or 6.1, the four records that have no fix on your branch outrank all of this, because no update clears them.

What is the new 7.2 row in the table?
Mainline 7.2 was released on 16 August 2026 and has since gained its own stable branch. 7.2.1 and 7.2.2 have been released, and 7.2.2 is now the newest stable kernel. Last week’s edition had no 7.2 row because the branch did not exist yet.

We do not build CAN, Bluetooth, MPTCP or vfio-ccw. Do these affect us?
Each bug is gated by a kernel config option, and the ones used in this advisory are CONFIG_CAN_J1939, CONFIG_TI_K3_AM65_CPSW_NUSS, CONFIG_MAC80211, CONFIG_BT with CONFIG_BT_LE, CONFIG_NF_FLOW_TABLE, CONFIG_NF_CONNTRACK_IRC, CONFIG_WCN36XX, CONFIG_OF_RESERVED_MEM, CONFIG_VFIO_CCW, CONFIG_MACVLAN, CONFIG_IPVLAN, CONFIG_IP_SCTP, CONFIG_MPTCP, CONFIG_CEPH_LIB and CONFIG_IO_URING. If the vulnerable code is not built into the kernel or available as a loadable module, the CVE is generally not reachable through that feature. Read a symbol set to m as still present and loadable rather than absent, and confirm dependencies, module-loading policy and vendor configuration before you close the finding.

Further reading

• linux-cve-announce, 23 to 29 August 2026
• CVE-2026-74752 (SCTP cookie AUTH) and CVE-2026-74746 (netfilter flow table)
• CVE-2026-80590 (the record that sets every branch target) and CVE-2026-80551 (s390 vfio-ccw)
• CVE-2026-74743 (macvlan) and CVE-2026-80722 (mac80211 S1G TWT)
• kernel.org active releases and projected end-of-life dates
• Previous edition: Linux Kernel CVEs, 16 to 22 August 2026