9,057 Patches Landed in One Stable Monday. Plan for Volume, Not Review.

The releases were 7.2.6, 6.18.52, 6.12.110, 6.6.157, 6.1.188, 5.15.221 and 5.10.270, all dated 14 September 2026 on kernel.org. Greg Kroah-Hartman noted that the batch may set a record for patch count. We have not checked the historical maximum, so we will not repeat that as a fact, but the stable kernel patch volume is straightforward to establish, because each review series states its own size in its subject line.

These are the series sizes as posted for review on 12 September. A patch can be dropped between the review posting and the release, so the released totals may differ slightly from these numbers.

Why stable kernel patch volume matters more than the changelog

The interesting figure is not the total. It is 1,191 patches on 6.1, and 935 on 5.15, and 798 on 5.10. Those are the series that embedded products actually pin to, and they are years past their feature freeze. A nine-year-old series taking 798 patches in one release is not receiving a handful of critical fixes. It is receiving a continuous backport stream from an automated selection process, and the volume is not going to fall.

Most embedded change-control processes were written for a different reality. They assume a stable update is small enough that an engineer can read the shortlog, decide which changes touch the subsystems the product uses, and sign off. At 798 patches that is perhaps two days of work per release, on a cadence of roughly one release a week, and the work has to happen again next week. Teams respond in one of two ways, and both are bad. They stop taking updates and freeze on a kernel that accumulates known vulnerabilities. Or they take updates without reading them and lose the ability to explain what changed when something regresses in the field.

What to replace review with

The defensible position is that you do not review the patches. You review the delta against the code you actually build, and you rely on testing for the rest. That turns an unbounded reading task into a bounded one.

Start by reducing the series to the files your configuration compiles. A shortlog of the whole release is not a useful artefact; a shortlog restricted to your subsystems is.

raghu@techveda.org:~$ git log --oneline v6.1.187..v6.1.188 | wc -l
1191
raghu@techveda.org:~$ git log --oneline v6.1.187..v6.1.188 -- \
    drivers/net/ethernet/ drivers/mmc/ drivers/spi/ drivers/i2c/ \
    arch/arm64/boot/dts/freescale/ | wc -l

Then separate the patches that can plausibly change behaviour on your hardware from the ones that cannot. Fixes carrying a CVE reference and fixes touching a driver you load are the two categories worth an engineer’s attention; the rest are covered by your test suite or not at all.

raghu@techveda.org:~$ git log v6.1.187..v6.1.188 --grep='CVE-' --oneline
raghu@techveda.org:~$ git diff --stat v6.1.187..v6.1.188 -- $(
    awk '/^CONFIG_.*=[my]$/{print}' .config | wc -l > /dev/null; echo drivers/ )

Finally, write down the rule and the evidence. A change-control record that says “took 6.1.188; 1,191 patches; 46 touch built subsystems; 7 carry CVE references; all reviewed; full regression suite passed on hardware” is auditable. A record that says “reviewed the stable update” is not, once the number is 1,191.

The part that is a product decision

None of this removes the underlying question, which is not an engineering one. Every one of these seven series has a different remaining lifetime, and the volume tells you something about what you are signing up for. Taking 6.1 means absorbing roughly a thousand patches per release until its end of life. Choosing a newer series means fewer backports per release but an earlier bring-up cost. Choosing to freeze means the patches stop arriving and the vulnerabilities do not.

That is a decision to make against real dates rather than intuition, which is what our kernel lifecycle tracker exists for. If your vendor BSP pins a series older than the one you would choose, the BSP tracker shows how far behind each vendor tree currently sits.

One thing worth stating plainly: taking fewer updates does not reduce your exposure, it only reduces your awareness of it. The patches were written because something was wrong. Declining them leaves the defect in your product and removes the record that would have told you.

Key takeaways

• All seven maintained stable and longterm series were released on 14 September 2026, carrying 9,057 patches between them as posted for review.
• The older longterm series are not quiet: 6.1 took 1,191 patches, 5.15 took 935, 5.10 took 798.
• Patch-by-patch review of a stable update is no longer a process a team can actually perform. Pretending otherwise produces change-control records that are not true.
• The workable replacement is a filter: reduce the series to files your configuration builds, then look at CVE-referenced fixes and loaded drivers, and rely on regression testing for the rest.
• Greg Kroah-Hartman described this batch as possibly a record. We did not verify that against history and do not assert it.

Frequently asked questions

Where does the 9,057 figure come from?
It is the sum of the patch counts stated in the subject lines of the seven review series posted on 12 September 2026, ranging from 1,815 for 7.2.6 down to 798 for 5.10.270. These are review-series sizes, so the released totals may differ slightly if a patch was dropped.

Was this really a record?
Greg Kroah-Hartman said it may set one. We did not check the historical maximum, so we cannot confirm it and the article does not claim it.

Should we take every stable release?
Taking them is the lower-risk default, because every patch exists in response to a defect. The question worth arguing about is not whether to take them but how to validate them, which is a testing problem rather than a reading problem at this volume.

Do older longterm series get fewer patches?
Fewer than the newest series, but not few. In this batch 5.10, which is the oldest maintained series, still took 798 patches in a single release.

Further reading

• kernel.org releases.json — the seven release dates, read directly
• LWN, 14 September 2026: More than 9,000 patches total in the seven stable kernels for Monday
• The 5.10.270-rc1 review posting on lore, showing its 798-patch count
• TECH VEDA kernel lifecycle tracker
• TECH VEDA BSP tracker

Building a defensible update and validation process for a shipped device is part of our Embedded Linux BSP Development training.