Linux 7.2.6 leads a 9,000-patch stable kernel batch

Greg Kroah-Hartman released seven Linux stable kernels together, carrying more than 9,000 patches between them. LWN.net reported the batch on September 14, 2026, and the advice attached to it is the usual one: upgrade. The volume is what makes this notable, and Kroah-Hartman flagged it himself.

The batch "may set a record for the number of patches with more than 9,000 in total between them," he wrote.

A stable kernel is a maintenance release. It takes an already-published kernel and adds fixes that were merged into the newest development kernel, without adding features. The practice is called backporting. It is how a distribution or a product can stay on one kernel version for years and still receive fixes.

The seven releases

Series	Release
7.2	7.2.6
6.18	6.18.52
6.12	6.12.110
6.6	6.6.157
6.1	6.1.188
5.15	5.15.221
5.10	5.10.270

Linux 7.2.6 carries the largest share on its own, at more than 1,800 patches.

How the count becomes visible

The patch count is not a summary written afterwards. It is in the subject line of the review posting.

Before a stable kernel ships, Kroah-Hartman posts the whole set to the kernel mailing list as a release candidate, for maintainers and users to test. The posting for this one is titled "[PATCH 7.2 0000/1815] 7.2.6-rc1 review", sent on September 12, 2026. The 0000/1815 is the patch numbering, so the series size is stated in the title of the first message.

That review window is the part worth knowing about. The patches are public for days before the release, which is the window in which a regression in your own workload can still be caught and reported.

What this means for developers

Treat the size as a scheduling fact, not a warning. A larger batch is not evidence of a lower-quality release. It does mean more changed lines reaching your systems in one step. It also means more surface for a regression that only you would notice.

Three practical moves. First, find which series you are actually on, with uname -r, and match it against the table above rather than assuming your distribution tracks the newest. Second, if you run anything with unusual hardware or an out-of-tree module, stage this on one machine before it reaches the fleet. Out-of-tree modules are the common source of surprise here, because nothing in the stable process tests them.

Third, if you do hit a regression, report it against the stable series rather than working around it locally. The review window exists for exactly that, and a fix that lands upstream reaches everyone on that series.

The one thing not to read into this is urgency about your kernel's lifespan. Neither the announcement nor LWN's write-up says any of these seven series is reaching end of life, so nothing here changes an upgrade deadline. The 5.10 and 5.15 series still receiving releases is itself the useful signal for anyone budgeting a long-lived product.

Separately, the same tree is preparing to shed weight: maintainers have a branch that would remove about 247,000 lines of old 32-bit ARM code. Read together, the two say something about where kernel effort goes. Backporting fixes to seven branches at once is the cost of supporting hardware for a decade, and deleting dead platforms is how maintainers try to keep that cost payable.