How Long Does a Linux Kernel Stay Supported? Stable, LTS, and Distribution Updates Explained
Learn how upstream stable and LTS branches, distribution kernels, backported fixes, and EOL dates determine whether your Linux kernel is supported.
AI-assisted, source-linked analysis. Product testing is only claimed when explicitly documented. How we work.
How Long Does a Linux Kernel Stay Supported? Stable, LTS, and Distribution Updates Explained
A Linux kernel is supported for as long as the organization responsible for that particular kernel package continues to maintain it—not simply for as long as its base version appears on kernel.org. If your distribution supplied the kernel, check the distribution release, package stream, security advisories, and lifecycle. If you installed an upstream or custom kernel, check its maintainer directly.
This distinction matters because distributions can backport fixes to an older-looking kernel package. An upstream branch reaching end of life does not automatically mean every distribution kernel derived from it stopped receiving fixes. Conversely, a relatively high version number does not guarantee that anyone still maintains the build you installed.
There is no single number of years that applies to every Linux kernel. The practical question is: Who maintains the kernel running on this machine, and is that maintainer still issuing applicable updates?
Who actually maintains your Linux kernel?
Start with how the kernel arrived on the system.
- Installed through a Linux distribution: Debian, Ubuntu, Red Hat Enterprise Linux, and other distributions package and maintain their own kernels. Their support policy, release lifecycle, package stream, and advisories are normally authoritative for users of those packages.
- Installed from kernel.org or compiled from upstream source: The active upstream branch and its maintainer determine whether new stable fixes are being released. You are also responsible for building, installing, and moving away from an EOL branch.
- Provided by a cloud, appliance, or hardware vendor: A cloud-optimized, OEM, embedded, or appliance kernel may have its own patch channel. The product vendor's lifecycle can matter more than the visible upstream base version.
- Installed from a third-party repository: Support depends on that repository or vendor. A package being downloadable does not prove that it receives timely maintenance.
“Linux” is therefore not one support contract. Two systems showing similar base versions can have different maintainers, patches, and end dates.
Mainline, stable, longterm, and release candidates
Kernel.org's active-release page uses specific terms:
- Prepatch or RC: release-candidate kernels used to test the next mainline release. They are development snapshots, not a general support choice for ordinary production systems.
- Mainline: the tree where new features are introduced. A new mainline version is released after its development and release-candidate cycle.
- Stable: after a mainline release, important fixes can be applied to its stable series by designated maintainers. Ordinary stable series often have a relatively short life.
- Longterm: selected kernel branches receive important fixes for longer than an ordinary stable series. These are commonly called LTS kernels.
- EOL: kernel.org's stable maintainers have stopped publishing fixes for that upstream branch.
Longterm does not mean “supported for exactly the same number of years every time.” Kernel.org publishes a projected EOL for each active longterm branch and warns that those projections can change. Use the live page rather than a copied version table.
Upstream support is not distribution support
Kernel.org explicitly separates its releases from distribution kernels. Most people receive a kernel through their operating-system package manager, and that package may contain distribution changes and backported fixes. Kernel.org tells users of such kernels to use the distribution's support channels.
Consider a distribution kernel based on an upstream branch that kernel.org no longer lists as active. The distribution may still maintain its package under the supported operating-system lifecycle. In that case, upstream EOL describes kernel.org's branch; it does not by itself establish that the distribution package is abandoned.
The reverse also matters. A kernel branch may still be active upstream while your operating-system release, third-party build, or vendor product has reached its own EOL. Upstream source availability does not promise that your provider will package and deliver those fixes.
Use kernel.org to understand upstream status. Use your distributor or product vendor to determine the status of the package you actually run.
Why an older version can still contain security fixes
A backport takes a relevant change developed for newer upstream code and adapts it to an older maintained codebase. This lets a distribution correct a security flaw or important bug while limiting unrelated changes that might break established systems.
Debian's security FAQ explains that Debian normally backports security fixes to the version shipped in its stable release instead of automatically moving to a new upstream release. Red Hat's backporting guidance similarly explains that the visible upstream base version can remain older while the distribution's package release changes to incorporate fixes. Ubuntu's kernel Stable Release Update process covers upstream stable updates, relevant bug fixes, CVE fixes, and hardware-enablement work for supported Ubuntu kernels.
Backporting is not a promise that every change is copied everywhere. Maintainers decide which fixes apply, adapt them to their code, test them, and publish package-specific updates. Different distributions and support streams make different decisions.
This is why neither of these shortcuts is reliable:
“My 5.x kernel looks older than a 6.x kernel, so it must be unsupported.”
“My version number is newer, so it must contain every security fix.”
Support status and vulnerability status require package and advisory context.
How to identify the running kernel
The standard read-only command is:
uname -r
It prints the release string for the kernel currently running. Distribution packages commonly add identifiers after the upstream-looking version, such as an architecture, flavor, ABI, build, or vendor suffix.
That output is an identifier, not a support verdict. By itself, uname -r does not tell you:
- whether your operating-system release is supported;
- whether the package came from an official repository;
- which fixes were backported;
- whether a newer installed kernel is waiting for a reboot;
- whether a particular CVE affects the system.
You also need the distribution and release context. Many distributions expose that information in /etc/os-release, which can be read safely:
cat /etc/os-release
Cloud images, appliances, containers, Windows Subsystem for Linux, and vendor products may require checking their own image or product documentation as well.
A support-status decision tree
Use this sequence rather than comparing your number with the newest kernel.org release.
- Did an operating-system distribution install and update the kernel?
- Yes: identify the distribution release and exact kernel package or stream. Check that distributor's lifecycle, security tracker, and advisories.
- No or unknown: determine whether it came from kernel.org, a custom build, a cloud image, an OEM, an appliance vendor, or a third-party repository.
- Is the operating-system or product release still supported?
- If not, a working kernel is not evidence of continuing security maintenance.
- Is this particular kernel stream covered?
- Some products offer multiple streams, such as a general-availability kernel, hardware-enablement stream, real-time kernel, cloud flavor, or extended-support channel.
- Is the system receiving the provider's updates?
- Check the configured repositories, package status, vendor advisories, and any pending transition notice.
- If it is an upstream or custom build, is its branch active?
- Check kernel.org or the named maintainer. If the branch is EOL, plan a move to a maintained branch.
If you cannot identify the maintainer or a current support policy, treat the kernel's maintenance status as unknown—not automatically safe or unsafe.
How representative distributions handle support
The following examples illustrate different models; they are not a lifecycle database.
Debian
For a Debian-supplied kernel, first check whether the Debian release is covered by current security support and whether the package comes from the relevant official suite. Debian publishes security information and advisories and documents its backporting approach in its security FAQ.
Do not compare only the base upstream number. Debian advises checking the exact Debian package version and the applicable Debian Security Advisory or package changelog. Also distinguish the main stable security archive from packages supplied through channels whose security coverage may differ.
Ubuntu
Ubuntu can provide general-availability, Hardware Enablement (HWE), OEM, cloud, real-time, and other kernel variants. Canonical documents these kernel variants and branches and provides a live Ubuntu lifecycle page for current coverage.
The operating-system release alone may not answer every question: identify the kernel stream and whether it is meant to roll forward to a later HWE stack. Use Canonical's current lifecycle and update documentation rather than assuming all Ubuntu kernels share one end date.
Red Hat Enterprise Linux
RHEL publishes a product and minor-stream lifecycle and errata policy. Supported packages receive applicable changes through Red Hat errata according to that policy and the active support channel.
Red Hat deliberately maintains stable package bases and backports relevant changes. For a CVE, check the Red Hat advisory or CVE record for the exact RHEL package and stream. A generic scanner that compares only the upstream base version can report a false positive when it misses the distribution's package release and backported fix.
Why CVE fixed-version comparisons can mislead you
An upstream advisory might say a fix entered a particular upstream release. That does not mean every package with a lower-looking base version remains vulnerable. A distribution may have backported the relevant change under its own package version.
It also does not mean every system on a higher version is unaffected. Configuration, included code, vendor changes, and whether the build actually contains the fix can matter.
The Linux kernel's CVE process documentation distinguishes active upstream trees from kernels maintained only by distributions. For a distribution package, consult the distribution's security advisory, tracker, and exact fixed package release. For an upstream build, use the upstream commit and supported stable-tree information.
The safe question is not “Is my number greater than the one in this headline?” It is “What does the maintainer of my exact package say about this issue?”
What upstream EOL means
When kernel.org marks a branch EOL, its upstream stable maintainer no longer issues bug-fix releases for that branch. Someone running an unmodified kernel.org build from that branch should plan to move to an active branch.
For a distribution kernel, take one additional step: check whether the distribution still maintains its derived package. Distribution support can continue under a separate lifecycle, but that must be established from the distributor's current policy and advisories—not assumed.
Likewise, do not keep an EOL operating-system release connected merely because it still boots or because its base kernel resembles an active branch. The distribution or product lifecycle governs the complete supported system.
Mainline, custom, OEM, and cloud kernels
Manually compiled and third-party kernels are not automatically unsafe. They do, however, move responsibility away from the ordinary distribution update path.
If you use one, document:
- the source repository and responsible maintainer;
- the exact branch and update channel;
- how fixes are selected, built, tested, and installed;
- who monitors EOL and security notices;
- how the system will transition to its next supported branch.
OEM and cloud kernels may be maintained by a distribution, hardware maker, cloud provider, or several parties working together. A vendor suffix in uname -r is a clue, not proof of coverage. Confirm the image, repository, package name, and vendor lifecycle.
When moving to a newer kernel makes sense
“Always install the newest upstream kernel” is poor universal advice. A supported distribution kernel may intentionally prioritize compatibility and tested backports over the newest feature release.
A transition becomes appropriate when:
- the responsible maintainer ends support for the branch, stream, OS release, or product;
- the distribution publishes a required migration path;
- newer hardware needs an enablement kernel;
- a required feature or unresolved bug is addressed in a supported newer stream;
- a custom build can no longer be maintained responsibly.
Installing an updated kernel package also does not necessarily change the kernel currently running. Traditional updates commonly take effect after booting the new kernel; some live-patching systems can apply selected fixes without that transition. For the operational response to an active vulnerability—including rollout and reboot planning—use our Linux kernel vulnerability patch guide.
Linux kernel support checklist
| Question | Where to check | What it tells you |
|---|---|---|
| What kernel is running? | uname -r |
The current release string, not its support verdict |
| Which OS release is this? | /etc/os-release and vendor image data |
Which lifecycle and repositories may apply |
| Who supplied the kernel? | Package manager, repository configuration, image or appliance documentation | The likely responsible maintainer |
| Is the OS/product supported? | Official distribution or vendor lifecycle | Whether normal maintenance should still exist |
| Is this exact stream covered? | Kernel-package, HWE/OEM/cloud, minor-stream, or subscription policy | Whether this variant follows a separate schedule |
| Is the upstream branch active? | kernel.org active releases | Upstream stable/LTS status; not distro-package status |
| How does the vendor handle fixes? | Official security policy and advisories | Whether and how relevant fixes are backported |
| Is a specific CVE fixed? | Vendor advisory/ tracker and exact package version | Package-specific status instead of a base-version guess |
| Has a transition been announced? | Release notes, lifecycle notices, support portal | What maintained stream the vendor expects next |
What not to do
- Do not assume the highest version number is automatically the safest choice.
- Do not replace a supported distribution kernel solely because kernel.org has a newer branch.
- Do not declare a distribution package vulnerable from an upstream version comparison alone.
- Do not treat a machine that still boots as proof that its OS or kernel remains supported.
- Do not install an unverified third-party kernel merely to obtain a larger version number.
- Do not assume “LTS” promises one universal number of support years; check the live branch or product policy.
Bottom line
To find out whether your Linux kernel is still supported, identify the running kernel, the operating-system or product release, the package stream, and the organization that supplies its updates. Then use that maintainer's current lifecycle and security advisories.
Kernel.org's active-release list is authoritative for upstream branches. It is not a substitute for Debian, Ubuntu, Red Hat, cloud, OEM, or appliance support information. An older-looking distribution kernel can include current backported fixes, while a newer unsupported build can have no reliable maintenance path. Support is a relationship with a maintainer, not a contest for the largest version number.