Greg Kroah-Hartman has released stable kernels 7.2.5 and 6.18.51. Each carries more than 550 patches of fixes spread across the tree.

The usual advice applies: all users of the affected series should upgrade.

What 550 patches means

That number surprises people who expect a stable point release to be a handful of security fixes. Stable kernel releases collect everything that qualifies under the stable rules, which is a broad category: security fixes, regressions, driver corrections, filesystem fixes, and anything else meeting the criteria of being an obvious fix for a real problem.

Most of it is driver work. The kernel supports an enormous amount of hardware, and the long tail of it generates a continuous stream of small corrections that individually matter to a few thousand people and collectively matter to everyone.

The volume is also why running a stale kernel is a worse idea than it appears. Skipping six point releases is not skipping six security advisories; it is skipping several thousand fixes, an unknown subset of which apply to your hardware.

Which one you want

7.2.5 is the current mainline stable series, tracking the 7.2 release from August. This is what you want on a desktop or anything where current hardware support matters.

6.18.51 is an LTS series, which is what most distributions ship and what long-lived servers should be on. LTS kernels receive fixes for years rather than weeks, and the backporting effort is exactly what you are relying on when you run a two-year-old kernel deliberately.

If you are on a distribution kernel, your vendor backports the relevant fixes into their own tree and the version number will not match upstream. That is normal. Ubuntu, Debian, and RHEL kernels carry version numbers that look old while containing current fixes.

# what you are running
uname -r

# on Debian or Ubuntu, what is available
apt list --upgradable 2>/dev/null | grep linux-image

Reboot required

Kernel updates do not take effect until you reboot, which is the step people skip. A patched kernel sitting on disk while the vulnerable one runs in memory provides no protection at all.

# Debian and Ubuntu will tell you
ls /var/run/reboot-required 2>/dev/null && echo "reboot needed"

# or check whether the running kernel matches the newest installed

Livepatching exists for exactly the case where rebooting is expensive, through kpatch, kGraft, or Ubuntu’s Livepatch service. It covers a subset of fixes, typically the security-critical ones, and is not a substitute for eventually rebooting.

For context on why these releases are large at the moment, the kernel is dealing with a sustained volume increase that has affected both development and the stable backporting workload.