Allgemein

Long-term support for Linux releases gets a new lease on life

Long-term support for Linux releases gets a new lease on life

If you want to keep your Linux instances safe and secure, your best course is to use Long Term Support (LTS) Linux kernels. They’re the ones that get all the bug fixes.

Now, once upon a time, the LTS kernels were supported for six years. Then, in 2023, the Linux kernel maintainers decided to cut LTS support to two years. Why? Because maintainers were burning out. That’s still a problem, but based on user feedback, Linux stable maintainer Greg Kroah-Hartman has decided to extend the existing LTS kernels’ supported life

On the Linux Kernel Mailing List (LKML), Kroah-Hartman writes that, “based on lots of discussions with different companies and groups and the other stable kernel maintainer [Sasha Levin],” they decided to extend support for several key releases into 2027 and 2028, and partially rolling back an earlier move to sharply limit LTS.

A longer lease on life for more recent kernels

Specifically, the new dates mean concrete, if modest, extensions for the main active LTS lines. According to the revised schedule, Linux 6.6 will now receive fixes through the end of 2027, while 6.12 and 6.18 are slated to be maintained until the end of 2028. That translates into roughly a four‑year window for 6.6 and 6.12, and at least three years for 6.18, significantly more than the two years that had become the new default for LTS trees in recent planning.

The Linux kernel long-term release schedule (credit: kernel.org).

No changes for 5.xx branches

However, the older 5.10 and 5.15 branches keep their existing December 2026 end‑of‑life dates, putting them on a clear path to retirement later this year. Kernel.org’s projections still list 6.1 as supported through December 2027, but the focus of this revision is on the newer 6.6, 6.12, and 6.18 trees that many distributions and vendors are either adopting now or lining up for their next cycles.

The new schedule does not restore the old six‑year promise, but it does push back against the strict two‑year limit for the current crop of LTS kernels. Such extensions are not unprecedented. Previous LTS branches have also been quietly lengthened when they became particularly important to downstream users, from enterprise distributions to embedded.

Why LTS matters

Security updates are the big reason to use LTS kernels. According to Jonathan Corbet, Linux kernel developer and LWN editor-in-chief, “In the kernel, just about any bug, if you’re clever enough, can be exploitable to compromise the system. The kernel is in a unique spot in the system […] it turns a lot of ordinary bugs into vulnerabilities.”

For the people who actually have to ship and support systems, the extra time is vital. LTS kernels underpin a wide range of products, from server distributions to Android devices and dedicated appliances. All these need years of security fixes without disruptive feature churn. Moving from one kernel series to another often requires redoing enablement, testing, and certification, which can be expensive and time-consuming, especially for hardware vendors.

Indeed, some Linux distros, such as Canonical’s Ubuntu, now offer their own LTS kernels with up to a dozen years of support, while Red Hat Enterprise Linux (RHEL) uses a single, heavily backported kernel per major version. For example, it still supports 5.14 on RHEL 9 and 6.12 on RHEL 10 for over 10 years, with security and bug‑fix backports. Both these initiatives are independent of kernel.org’s LTS branches.

With 6.6 supported through 2027 and 6.12 and 6.18 through 2028, distributors and OEMs now have more room to align their own long‑term offerings and migration paths, rather than being forced into faster kernel jumps. The flip side is that projects still anchored on 5.10 or 5.15 now have clear pressure to plan upgrades before those branches lose upstream security coverage at the end of this year.

 

The post Long-term support for Linux releases gets a new lease on life appeared first on The New Stack.