Greg Kroah-Hartman released seven stable Linux kernels on Friday, July twenty fourth, covering every maintained branch at once: 7.1.5, 6.18.40, 6.12.97, 6.6.145, 6.1.178, 5.15.212 and 5.10.261. The size is what makes this one worth planning for rather than rubber stamping. The 7.1.5 candidate carried more than two thousand patches and the 6.18.40 candidate carried 1,611, which is a large batch by any measure of the stable series. If you run fleets on a mix of branches, the useful question is not whether to take it. It is what order you take it in, and what you watch afterwards.
The short answer
On Friday, July twenty fourth, Greg Kroah-Hartman released 7.1.5, 6.18.40, 6.12.97, 6.6.145, 6.1.178, 5.15.212 and 5.10.261, refreshing the stable series and every maintained long term support branch on the same day. The two newest carried unusually heavy patch loads. Two changes deserve targeted testing: a data corruption fix for XFS, and a BPF verifier mismatch on s390 flagged as a regression. Linux 7.2 is at release candidate four and is expected as a stable release in August, so this batch is the update to plan around now.
Most stable kernel announcements are a line in a mailing list and a package update three days later. This one is worth ten minutes of your attention, not because anything dramatic happened, but because of the volume. On Friday, July twenty fourth, seven kernels went out at once and two of them were carrying several times the usual number of changes.
What went out
The list is 7.1.5, 6.18.40, 6.12.97, 6.6.145, 6.1.178, 5.15.212 and 5.10.261. That is the current stable series plus every long term support branch still under maintenance, all refreshed on the same day. Tarballs are on kernel.org, and for most readers the practical delivery path is a distribution package that lands within a few days.
The weight is the notable part. The 7.1.5 candidate carried more than two thousand patches. The 6.18.40 candidate carried 1,611. A routine point release on a settled branch is often a few hundred, so the two newest branches took several times their usual load in a single cycle. The older branches were far lighter, which is exactly what a mature branch should look like, since backports that still apply cleanly to 5.10 get rarer every year.
Two things to test on purpose
A large batch is not automatically a risky batch, but there are two items here specific enough to test rather than assume.
The first is a fix for data corruption on XFS. If you run XFS under anything you would be unhappy to lose, treat this as a release to schedule rather than defer, and take the opportunity to verify that a restore from your backups actually works. Corruption fixes are the category where the cost of being late is measured in data rather than downtime.
The second is a verifier mismatch affecting BPF on s390, flagged as a regression. That is a narrow surface, but if you run BPF tooling on IBM Z it is your surface, and a regression is precisely the thing that a large batch can carry along with everything else. Exercise that path deliberately on a canary before you roll to a ring.
Which branch you should be on
If you are refreshing hardware or standardising a new fleet, 6.18 is the newest long term support branch and therefore the one with the longest runway. Systems already settled on 6.12 or 6.6 are on reasonable ground and do not need to move for this release.
The branches worth thinking about are 5.15 and 5.10. They are still maintained, they still receive these updates, and they are also late in their life. Every month spent there widens the jump you eventually have to make, because the further two branches drift apart the more of your out of tree modules, driver quirks, and tuning assumptions have to be revalidated at once. If you are still standing up new machines on 5.10 in mid 2026, the branch choice is the item on your list, not this point release.
Do not wait for 7.2
Linux 7.2 reached release candidate four around the same time as this batch, and the stable release is expected in August. It is on track to become the default kernel in autumn distribution releases, Ubuntu 26.10 among them.
That is a reason to take this update now rather than a reason to hold for something newer. Production kernel decisions follow your distribution's shipping schedule, not the mainline tag date. Apply the stable release for the branch you already run, keep a canary in each ring, and evaluate 7.2 when it arrives packaged and tested by the people who support your systems.
Sources and further reading
- LWN: Hefty stable kernel updates for Friday
- Linux Compatible: Linux Kernel 6.18.40 and five LTS branches released in a large July stable cycle
- Phoronix: Linux 7.2-rc3 released, close to the new normal
- The New Stack: Linux 6.18, all about the new long term support kernel
Frequently asked questions
Which kernel versions were released on July twenty fourth?
Greg Kroah-Hartman announced 7.1.5, 6.18.40, 6.12.97, 6.6.145, 6.1.178, 5.15.212 and 5.10.261 on Friday, July twenty fourth, 2026. That is the current stable series plus every long term support branch still under maintenance, refreshed on the same day. Source tarballs went up on kernel.org as usual, and distribution vendors normally fold the changes into their own kernel packages over the following days, so most people will meet these updates through their distribution rather than by building from source.
How big was this batch compared to a normal stable release?
Larger than usual on the newer branches. The 7.1.5 release candidate carried more than two thousand patches, and the 6.18.40 candidate carried 1,611. A routine stable point release on a mature branch is often a few hundred patches, so these two are several times the usual weight. Older branches were much lighter, which is what you would expect, since a branch like 5.10 has been maintained for years and only receives backports that still apply cleanly to a codebase that has stopped moving.
Which LTS branch should I be standardising on?
6.18 is the newest long term support branch, which makes it the sensible target for fleets that are refreshing hardware or want the longest runway ahead of them. 6.12 and 6.6 remain reasonable middle ground for systems already standardised there. The 5.15 and 5.10 branches are still maintained but they are late in life, and every month you stay on them the gap you eventually have to jump gets wider. If you are still building new systems on 5.10 in mid 2026, the branch choice is the thing to fix, not this particular point release.
What should I watch after applying this update?
Two items in this batch are worth targeted testing. There is a fix for data corruption on XFS, so if you run XFS on anything that matters, this is a release to move on rather than defer, and a good moment to confirm your backups actually restore. There is also a verifier mismatch affecting BPF on s390 that was flagged as a regression, so if you run BPF tooling on IBM Z, test that path deliberately before rolling wide. Everything else follows normal practice: boot a canary, watch your storage and network paths, then proceed by ring.
When does Linux 7.2 arrive?
Linux 7.2 is in the release candidate stage, with 7.2-rc4 out around the same time as this stable batch, and the stable release is expected in August 2026. It is expected to become the default kernel for autumn distribution releases including Ubuntu 26.10. For production planning that means 7.2 is not a decision you need to make now. Take the stable update for the branch you are on, and evaluate 7.2 when your distribution ships it rather than when the mainline tag appears.