The Linux kernel shipped 227 CVEs in one week and left four flaws unfixed on older branches
Between 23 and 29 August 2026, the Linux project published 227 CVEs, five times a normal week, as a full stable cycle landed on 28 August across all eight active branches. Update to the latest release on your branch, but track the four flaws that no stable fix covers separately.
28 August 2026. Greg Kroah-Hartman ships eight stable kernels at once. 23–29 August 2026. The Linux project issues 227 CVEs, roughly five times an ordinary week. 16 August 2026. The 7.2 branch leaves mainline and already receives its second point release. The news is not a spectacular bug: it is a step change in how the kernel publishes vulnerabilities — and in how teams must handle them.
Why 227 CVEs landed at once
The number looks alarming; the cause is administrative, not technical. The identifiers tell the story: 21 CVEs sit in the CVE-2026-747xx block, the other 206 in the CVE-2026-805xx through 807xx block. On 28 August, the project cut a point release on every active branch at the same time, and the records for everything in those releases were published together.
The previous week, the same tracker listed six CVEs. The jump to 227 does not mark a collapse in kernel quality — it reflects the rhythm of a full stable cycle. Most of the fixes are narrow: a buffer overflow here, a missing validation there. Few of them look anything alike, and almost all of them shipped in the kernels released that same day.
Two caveats matter before anyone panics. First, none of the 227 is reported as exploited, and no public exploit had been found at the time of writing. Second, NVD has not finished analysing the batch: the CVSS scores quoted here are the kernel CNA’s own, carried as secondary metrics. Other vendors and enrichment databases will publish different figures. Prioritise by reachability and deployment context, not by the score alone.
CVE-2026-80590, the flaw that set every branch target
A single record, CVE-2026-80590, sets the target on all eight stable branches by itself. The flaw leaves stale GSO state on IPv4 fragments before reassembly: an unprivileged user can mark fragments as GSO and trigger a kernel panic. It is a local denial of service, but one that takes down the entire host.
The telling detail is elsewhere: CVE-2026-80590 is fixed only in the stable branches and names no mainline entry. It is, in practice, the reason this week’s numbers are what they are. Two other records also name no mainline fix: CVE-2026-80724 and CVE-2026-74753.
For administrators the consequence is simple. The eight target versions — 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 — are all the newest release of their branch, and all eight were cut on 28 August. On an upstream kernel the check is binary: if you are not on the latest release of your branch, you are behind.
Four flaws a branch update does not clear
This is the part to read before closing the ticket. Four records mark a branch as affected without naming a fixed version for it. Installing the table target does not remediate them.
- 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. The widest gap of the week.
- CVE-2026-80551 (s390 vfio-ccw, CVSS 9.3): introduced in 5.3, fixed in 6.6.154 and later. No fix 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 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 for 5.10 or 5.15.
Add last week’s CVE-2026-74582, still unfixed on 5.10, 5.15 and 6.1. A team shipping one of the older LTS branches now has five items to track separately from the branch bump.
The pattern is telling: the older the branch, the more flaws the stable flow no longer catches up on. That is not negligence — it is the cost of an end-of-life branch, where every backport grows more expensive to produce.
How to triage 227 CVEs without losing a week
The method is three steps, in order.
- Check the version.
uname -r, then compare against the target for your branch. Everything is already out: nothing waits on a future release. - Confirm the feature is built and reachable. Every bug is gated by a config option:
CONFIG_IP_SCTP,CONFIG_MACVLAN,CONFIG_WCN36XX,CONFIG_VFIO_CCW,CONFIG_MAC80211, and so on. A symbol set tomis still present and loadable, not absent. - Ship the right kernel. Apply the newest upstream release of your branch, or a verified vendor backport equivalent to the target.
# Current kernel version
uname -r
# Is the vulnerable feature compiled in or loadable?
grep -E 'CONFIG_(IP_SCTP|MACVLAN|WCN36XX|VFIO_CCW)' /boot/config-$(uname -r)On a vendor or BSP kernel the version does not compare cleanly with the table. A kernel reporting 5.10.110-rk3588 is based on 5.10.110 and will never become 5.10.268 through an upstream update. For those products the table tells you which fixes must be present, not which release to install. Ask the silicon vendor, and treat a verified backport as equivalent to the target.
What this volume changes for maintenance
This is not the first time the kernel has shipped a large batch, but the scale changes the practice. A team that still tracked CVEs one by one — reading the record, judging whether it applies, hunting for the commit — drowns at 227 in a week. The stable-branch model offers a mechanical answer: for the vast majority of flaws, the fix is already in the newest point release of the branch. Updating the version therefore clears the batch at once, with no manual backport.
The corollary matters just as much. If a team cannot update — a locked kernel, a certification, a vendor BSP — the volume becomes unmanageable, because every individual backport is a porting and validation effort of its own. That is where the four unfixed flaws change nature: on an old LTS, the branch update does not cover them, and you must decide, one by one, whether the risk justifies a backport the stable flow never shipped. The real cost of maintaining an end-of-life branch is no longer the fix — it is the triage.
The good news is that the kernel made the tracking transparent: records are published on the linux-cve-announce list, readable on lore.kernel.org, and every stable release documents the fixes it carries. The information is there; what teams still lack is the reflex to patch by branch version rather than by CVE.
Verdict
If you run a recent upstream kernel, updating to the newest release of your branch settles most of it: all 227 CVEs, including CVE-2026-80590, are already fixed in the eight targets published on 28 August. Do it before your next maintenance window and the bulk of the batch is done.
If you ship an older LTS branch — 5.10, 5.15 or 6.1 — or a vendor BSP kernel, the update is not enough: four flaws from this week, plus one from last, remain unfixed. Track them explicitly, quantify the residual risk, and ask your vendor the real question: is the branch still worth maintaining, or is it time to plan a move to a newer LTS?
References
- Stable releases 7.2.2, 7.1.12, 6.18.48, 6.12.107, 6.6.155, 6.1.186, 5.15.219, 5.10.268 — LWN.net, 28 August 2026
- Linux Kernel CVEs to Patch by Device: 23–29 Aug 2026 — TechVeda, 29 August 2026
- CVE-2026-80590 — CVE.org
- CVE-2026-74752 (SCTP cookie AUTH) — CVE.org
- CVE-2026-80551 (s390 vfio-ccw) — CVE.org
- CVE-2026-74743 (macvlan) — CVE.org
- CVE-2026-80635 (wcn36xx Wi-Fi) — CVE.org
- kernel.org — active releases
- linux-cve-announce, 23–29 August 2026 — lore.kernel.org