Greg Kroah-Hartman and Sasha Levin pushed four stable kernel releases into the tree: 7.1.8, 6.18.44, 6.12.103, and 6.6.151. Between them they carry hundreds of targeted bug fixes and security patches across the block layer, networking stack, and major filesystems, with no new features.

The announcement text is the usual one, and worth quoting because it says exactly what a stable release is for:

This is a stable release containing fixes for regressions and other issues. These fixes have been tested against the linux-stable testing tree and have been applied for some time. We encourage all users to review and test this new stable kernel.

The AMDGPU regression

The 7.1.8 release fixes a brightness bug that affected 7.1.6 and 7.1.7 on AMD graphics. If you are on an AMD laptop running either of those versions and your brightness controls stopped behaving, this is your fix rather than a hardware problem.

Regressions inside a stable series are the awkward case. The whole premise of stable branches is that updates are safe, and a brightness bug shipping in two consecutive point releases is the sort of thing that trains people to defer updates. Worth noting that it was caught and fixed quickly.

Which branch you are on

The LTS branches have different lifespans, and picking one is a real decision for anyone maintaining servers:

• 6.18 is the freshest LTS, shipped in late 2025, supported through December 2028
• 6.12 sits in the middle of the range
• 6.6 is the longest-tested of the group, supported until December 2027

The tradeoff is the obvious one. Newer LTS branches carry better hardware support and a longer support window; older ones have had more eyes on them and fewer surprises left.

# What are you running?
uname -r

# Debian and Ubuntu
sudo apt update && sudo apt full-upgrade

# Fedora
sudo dnf upgrade --refresh

# Arch
sudo pacman -Syu

Remember that a kernel update does not take effect until you reboot, and that uname -r reports the running kernel rather than the newest installed one.

On the CVE volume

If the number of fixes in a stable release looks alarming, it is worth revisiting why. The kernel became its own CNA in 2024 and now assigns CVEs to essentially every fix that could conceivably have a security implication, which produces enormous CVE counts that do not map to enormous risk.

We covered that in detail when the kernel published 432 CVEs in two days. The practical guidance has not changed: track a stable branch, apply its updates, and do not try to triage individual kernel CVEs unless that is specifically your job.