Linux Kernel End of Life - Dates and Lifecycle

The Linux kernel's version numbers don't carry the significance they might suggest. Linus Torvalds bumps the major number when the minor number feels too large to keep track of, not because of some milestone, which is why kernel 7.0 and 7.1 have already shipped without marking any dramatic shift from the 6.x series. What actually matters for tracking support is whether a given release is a short-lived stable kernel or one of the small number designated as long-term support.

Linux Kernel Lifecycle Explained

Most kernel releases are ordinary stable releases, superseded by the next one after roughly two months, at which point they stop receiving any further fixes. A small subset of releases are designated long-term support (LTS), and these get years of backported security and bug fixes instead. LTS support windows have shifted more than most software in recent years: they ran six years historically, were cut to a 2-year default in 2023 as maintainers cited burnout from supporting so many branches at once, and were then partially extended again in early 2026 after industry pushback. As it stands now, Linux 5.10 and 5.15 are supported for six and five years respectively, 6.6 and 6.12 for four years each, and 6.18 for at least three years, with further extensions possible depending on industry demand.

Here's the important distinction for how much this actually matters in practice: unlike a language runtime or framework, the raw upstream kernel.org lifecycle isn't usually what determines real-world risk. Linux distributions like Debian, Ubuntu, and RHEL take a specific kernel version and back-port security fixes into it for the life of that distribution release, often well past the point where kernel.org itself has stopped maintaining that exact version. So a server running "an EOL kernel version" by kernel.org's own tracking may still be fully patched, because its distribution vendor is handling security fixes independently. The distribution's own end of life date, covered on this site's Debian and CentOS pages among others, is generally the more meaningful thing to track for production risk than the raw kernel.org branch status.