Plan around longterm kernel end of life by recording which kernel series each firmware release ships, comparing it to the projected end of life dates on kernel.org, and scheduling the move to a newer series well before the date. Devices that cannot take a new series need a stated plan, not silence.
What the kernel project says
The Linux Kernel Archives describe several categories: mainline, stable, and longterm. A longterm kernel exists to backport bugfixes for older trees, and only important fixes are applied to it. The page also lists projected end of life dates for each longterm series. When this post was checked, the page listed series 5.10 and 5.15 with a projected end of life of December 2026, 6.1 and 6.6 with December 2027, and 6.12 and 6.18 with December 2028. Dates can move, so read the live page before you plan.
It also says that a distribution kernel, one you did not download and compile from kernel.org, may or may not be based on the maintained trees, and kernel developers can provide no support for it. If your firmware uses a vendor kernel from a chip supplier, ask that supplier what their support window is.
Steps for a fleet owner
- Find the kernel in every live release. Your release SBOM should list it. If it does not, the running device reports it.
- Classify each kernel. Mainline longterm series, distribution kernel, or vendor fork.
- Write down the end of life. For vendor forks, ask for a written date.
- Count devices per series. The number on a series that is near end of life is your exposure.
- Work backward. Allow time for porting drivers, regression testing, and a staged rollout. A kernel move is not a patch.
- Decide for devices that cannot move. Options include retire, replace, limit network exposure, or accept with a dated review.
A simple tracking table
| Release | Kernel series | Source | Support ends | Devices |
|---|---|---|---|---|
| 3.8 | 5.15 | Chip vendor fork | Ask vendor | Fill in |
| 4.1 | 6.6 | Mainline longterm | See kernel.org | Fill in |
| 4.2 | 6.12 | Mainline longterm | See kernel.org | Fill in |
Why this is a supply chain issue
The kernel is a component like any other, but it is the one whose fixes you cannot simply swap. Moving a series touches drivers, boot, and sometimes hardware support. Treating it as a calendar item with an owner is the cheapest way to avoid a fleet running an unmaintained kernel.
Safeguard can help you find kernel and OS package versions across stored SBOMs and flag end of life components. Start with the free scan at gold.safeguard.sh/scan.
Common traps
A version string can mislead. A vendor kernel may carry a familiar number while missing fixes that landed in the maintained tree, or include fixes backported in a way the number does not show. Ask the supplier how they track upstream fixes and how fast they pass them on. Also check the bootloader and device tree: a kernel move that works on your dev board can fail on an older hardware revision still in the field. Keep a test unit of every revision you support.
Quick check
Does a longterm kernel get every fix?
No. The kernel archive notes that only important bugfixes are applied to longterm kernels.
Who supports a vendor kernel?
The vendor that supplied it. Kernel developers say they can provide no support for distribution kernels.
Sources
Last reviewed: 19 October 2026.
