Since 2023 the default kernel LTS support window for a new long-term-support kernel is two years, down from the earlier six. In February 2026 the stable maintainers extended the projected end-of-life dates for several active branches, so some 6.x LTS kernels are now maintained through 2027 or 2028, but the two-year default still stands for new releases. For embedded teams this means you can no longer assume a long support tail by default. Choose your LTS base deliberately, track its published end-of-life date, and plan a kernel update before that date or arrange extended support separately.
The length of upstream kernel LTS support directly affects how long an embedded product can ship security fixes without a kernel change. That window has become shorter and less predictable than it was a few years ago. This article sets out what the current kernel LTS support timelines actually are, using the dates published on kernel.org, and what an embedded team should do about them. The aim is a practical, evidence-based view for product planning, not a general overview of the release process.
What changed in the kernel LTS support policy
For years, a long-term-support kernel was maintained for six years. In 2023 the stable maintainers, led by Greg Kroah-Hartman, reduced the default support period for new LTS kernels to two years. The stated reasons were the maintenance burden of backporting fixes to old trees and the limited real-world testing those old LTS branches received. The policy did not change any code; it changed how long a new LTS branch would receive backported fixes by default.
One kernel per year becomes the LTS release, and it is normally the last major version released in that calendar year. Linux 6.18, released at the end of 2025, was promoted to LTS on 3 December 2025 and was initially marked as maintained for two years, through December 2027.
The current LTS timelines
On 25 February 2026, Greg Kroah-Hartman updated the projected end-of-life dates for several active LTS branches on the kernel.org releases page, following discussions with companies and the other stable maintainer, Sasha Levin. The revised projections are:
- Linux 6.18 — projected support through December 2028.
- Linux 6.12 — projected support through December 2028.
- Linux 6.6 — projected support through December 2027.
- Linux 6.1 — projected support through December 2027.
- Linux 5.15 — projected support through December 2026.
- Linux 5.10 — projected support through December 2026.
Two points are worth stating clearly. First, these are projected end-of-life dates on kernel.org, and the update revised documentation rather than making any technical change to the kernels. Second, the extensions apply to specific existing branches, particularly the widely used 6.x series; they do not restore a six-year default for new LTS kernels. A kernel promoted to LTS today still starts with a two-year commitment.
Why the shorter default matters for embedded products
Embedded products often stay in the field for many years, far longer than a desktop or server install. A network appliance, an industrial controller, or a medical device may need security updates for five, ten, or more years. The kernel LTS support window sets how long you can take upstream stable fixes for your chosen base without moving to a newer kernel.
When the default window was six years, a team could pick an LTS kernel and reasonably expect fixes for most of a product’s supported life. With a two-year default, that assumption no longer holds. If you select a kernel at the start of a two-year hardware development cycle, the upstream branch may reach end-of-life not long after the product ships. After that date, no more stable backports arrive from upstream, and the responsibility for security fixes shifts to you or to a third party.
How to plan around it
The shorter window does not prevent long-lived embedded products, but it requires deliberate planning rather than assumptions. A reasonable approach:
- Choose the LTS base deliberately. At design time, pick a current LTS kernel and read its published end-of-life date on the kernel.org releases page. Prefer a recently released LTS so the remaining support window is as long as possible.
- Record the end-of-life date in the product plan. Treat it as a hard planning input, alongside component availability and certification dates.
- Budget for at least one kernel update. If the product life exceeds the support window, plan and cost a kernel uplift before the branch reaches end-of-life, including driver forward-porting and re-testing.
- Consider extended-support options for very long lifecycles. The Civil Infrastructure Platform (CIP) maintains selected kernels as super-long-term support for at least ten years, and some commercial vendors offer similar extended maintenance. These are separate from the upstream stable process.
- Track your actual base, not the vendor label. Vendor board support packages are often based on an older kernel than the latest upstream. Confirm the real base version and its upstream status.
You can check the base version of a running system or a BSP kernel directly:
raghu@techveda.org:~$ uname -r
6.6.30-imx-1.0.0Here the numeric prefix, 6.6, identifies the upstream LTS branch the vendor kernel is based on, which is what you match against the kernel.org end-of-life date. The vendor suffix indicates board-specific patches on top of that base. Understanding how a vendor BSP maps back to an upstream LTS branch is part of the board bring-up and maintenance work covered in our Embedded Linux training.
Key takeaways
- Since 2023, the default kernel LTS support window for a new LTS kernel is two years, reduced from six.
- In February 2026 the maintainers extended projected end-of-life dates for several active branches: 6.18 and 6.12 through 2028, 6.6 and 6.1 through 2027, and 5.15 and 5.10 through 2026.
- Those extensions are documentation updates for specific branches and do not restore a six-year default for new LTS kernels.
- Embedded products often outlive a two-year support window, creating a gap where upstream stable fixes stop before the product is retired.
- Plan for it: choose the LTS base deliberately, record its end-of-life date, budget for a kernel update, and consider CIP or commercial extended support for very long lifecycles.
Frequently asked questions
How long is a Linux LTS kernel supported now?
By default, a newly promoted LTS kernel is supported for two years, reduced from six in 2023. Individual branches can be extended later; as of February 2026, Linux 6.18 and 6.12 are projected through December 2028, 6.6 and 6.1 through December 2027, and 5.15 and 5.10 through December 2026.
Did the February 2026 extensions restore six-year LTS support?
No. The maintainers extended the projected end-of-life dates for several existing branches, mainly the widely used 6.x series, but the default for a newly promoted LTS kernel remains two years. The update revised the dates published on kernel.org and did not change any kernel code.
What should embedded teams do about the shorter support window?
Choose the LTS base deliberately at design time, record its published end-of-life date as a planning input, and budget for at least one kernel update if the product will outlive the support window. For very long lifecycles, consider extended-support options such as the Civil Infrastructure Platform.
How do I find which upstream LTS branch my vendor kernel is based on?
Run uname -r and read the numeric prefix, such as 6.6, which identifies the upstream branch; the vendor suffix indicates board-specific patches. Match that prefix against the end-of-life date on the kernel.org releases page.
Further reading
- Active kernel releases and projected end-of-life dates — kernel.org.
- Linux Kernel LTS Support Extended for Multiple Releases — Linuxiac, February 2026, with the maintainer commit link.
- Linux 6.18 Officially Promoted To Being An LTS Kernel — Phoronix, December 2025.
- Civil Infrastructure Platform — super-long-term support kernels for industrial use.
