What Skipping a Kernel Upgrade Costs an Embedded Product

Leaving an embedded product on an old kernel has costs that grow with time. Each kernel series receives fixes only for a limited period, and once it reaches end of life the fixes stop, new CVE identifiers stop being issued for defects found only in it, and new drivers never arrive. The longer a team waits, the larger the eventual kernel upgrade becomes, which is why keeping current within a series and planning the move to the next one should both be routine work rather than an emergency.

Many product teams upgrade the kernel only when something forces them to. That is a reasonable position. The kernel on the board is the kernel the team tested, qualified and shipped, and every kernel upgrade carries risk and cost. This article looks at the other side of that decision for embedded product teams: why a kernel upgrade deserves a regular place on the product plan, what happens to a product that stays on a stale kernel, and what to weigh when the upgrade is planned. Our earlier piece on the five support clocks a product carries describes the deadlines a product lives with; this one explains why the kernel’s support period should be planned for rather than reacted to.

Why teams postpone a kernel upgrade, and when that is defensible

The reasons for staying on a qualified kernel are real. A vendor BSP was delivered on a particular version and the vendor supports only that version. Out-of-tree drivers and private patches were written against it. For a certified industrial, medical or automotive product, any kernel change reopens part of the qualification evidence, and the cost of re-testing and re-documenting is usually larger than the engineering work itself.

The strongest form of this position goes further. A device on a closed network, with a documented threat model and a supplier contracted to deliver fixes for defects inside that model, can argue that most kernel defects never reach it. For such a team, a frozen kernel is a deliberate and priced decision, not neglect.

That position holds only while three conditions hold. Someone must still be producing fixes for the series. Someone must be able to tell the team which newly found defects affect it. And the distance to a supported series must stay small enough to cross when the team finally has to move. End of life removes the first two conditions, and time removes the third. The rest of this article is about those three conditions.

How kernel support works

kernel.org releases a new mainline kernel every nine to ten weeks. Each release then becomes a stable series that receives bug fixes, but a stable series usually gets only a few bug-fix releases before the next mainline kernel appears, unless it is designated a longterm maintenance kernel. Products ship on longterm series because they are the only ones maintained for years rather than weeks. kernel.org describes them as provided “for the purposes of backporting bugfixes for older kernel trees”, and warns that “only important bugfixes are applied to such kernels and they don’t usually see very frequent releases, especially for older trees”.

Every longterm series has an end. kernel.org states that each new longterm kernel “usually starts with only a 2-year projected EOL that can be extended further if there is enough interest from the industry at large”, and that the dates “are not set in stone”. At the time of writing, the longterm table looks like this:

Series	Released	Projected end of life
6.18	2025-11-30	December 2028
6.12	2024-11-17	December 2028
6.6	2023-10-29	December 2027
6.1	2022-12-11	December 2027
5.15	2021-10-31	December 2026
5.10	2020-12-13	December 2026

Two things in this table matter for planning whenever it is read. First, every series ends, and even the newest one is projected to end a little over two years from the time of writing. A product that will be in the field for ten years will therefore cross several kernel series, whatever it starts on. Second, support time does not always grow with the version number. A newer series is not guaranteed to last longer than its predecessor, and two neighbouring series can share an end date, as 6.1 and 6.6 do here. A team planning a kernel upgrade should compare projected end-of-life dates, not version numbers.

What happens to a product on a stale kernel

Fixes stop arriving

While a longterm series is supported, the volume of fixes it receives is large. Counting the published release notes for the twelve months to 30 October 2026, the 6.1 series received 10,836 fixes across 33 point releases, and 6.12 received 15,773 across 59. Even 5.10, the oldest series in the table, received 6,096 in the same period.

At end of life that number becomes zero. The fixes do not stop being written; they continue to land in mainline and in the supported series. They simply stop being ported to yours, and every fix the product needs from then on is one the team has to find, port and test itself.

CVE identifiers stop being issued

This consequence is less obvious and matters more to any team whose release process depends on CVE tracking. The kernel’s own CVE documentation, in Documentation/process/cve.rst, states: “No CVEs will be assigned for any issue found in a version of the kernel that is not currently being actively supported by the Stable/LTS kernel team.”

The reason is structural. A kernel CVE record is built from a fix, and the documentation says assignment happens only “after a fix is available and applied to a stable kernel tree”. With no supported tree to receive the fix, there is nothing to build the record from. A defect found after end of life in code that only that series still carries will have no kernel.org CVE at all. A process that reports “no open CVEs for our kernel” will then return a clean result because assignment has stopped, not because the code is safe. For products sold in the EU, where the Cyber Resilience Act makes vulnerability handling a legal obligation, that gap is a compliance problem as well as a technical one; we covered the obligations in kernel CVEs and the Cyber Resilience Act.

Backporting fixes yourself is not a substitute

The usual alternative to a kernel upgrade is to keep the qualified kernel and backport individual fixes as they are published. The kernel community does not support that approach. Every published CVE record carries the same paragraph: “Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all.” The process documentation gives the reason: “for many bugs, the solution to the overall problem is not found in a single change, but by the sum of many fixes on top of each other.” A single backported commit can therefore leave a defect present while the tracking sheet shows it as closed.

Reading CVE records also needs care. Each record lists, series by series, where a defect was introduced and where it was fixed. A record that says a defect is fixed in a later release says nothing about whether your series has a fix; only the line for your series answers that.

New hardware stops arriving

The stable rules state that a change “must either fix a real bug that bothers people or just add a device ID”. A new device ID for an existing driver can reach your series. A new driver cannot, even while the series is fully supported. When a component on the board reaches end of life and its replacement needs a driver that appeared in a later kernel, the product needs a kernel upgrade at a time chosen by the component supplier rather than by the team.

The kernel upgrade gets bigger every month

A product that took a BSP at 6.1.158, released on 29 October 2025, and did not update for a year would have been 33 releases and roughly eleven thousand changes behind 6.1.191, a tree built to be a drop-in replacement for the one it ran. Those changes do not arrive at an even rate. Across those 33 releases, the number of fixes per release ranged from 1 to 1,880, with a median of 79. A plan to review every incoming change will work for a month and then meet a release of 1,880. Meanwhile any private patches the team carries keep diverging from upstream, which we have written about in the cost of out-of-tree drivers and private kernel patches.

Two decisions: keeping current and moving series

A kernel upgrade is two different decisions, and they should be planned and priced separately.

The first is the point-release update inside your series, for example from 6.1.158 to 6.1.191. Because the stable rules admit only bug fixes and new device IDs, a point release is not expected to restructure configuration or driver interfaces or to change user-space behaviour. The rules do not guarantee any of that, so it still needs testing, but the risk is bounded and the change can be reversed by returning to the earlier release.

The second is the series migration, for example from 6.1 to 6.12. Here internal interfaces change, drivers are reworked or removed, configuration options are renamed, and every out-of-tree driver or private patch has to be rewritten against the new tree. This is what teams mean when they say a kernel upgrade is expensive, and they are right.

There is no reason to postpone the first decision while debating the second. Keeping current within a series is the low-cost part, and it makes the eventual migration smaller, because the fixes already in your tree are fixes you do not have to recognise again inside a much larger change. In practice that means taking point releases as a routine part of every product release, and starting a series migration well before the current series reaches its projected end of life rather than after it.

What to consider before a kernel upgrade

Which series to move to. Compare projected end-of-life dates, not version numbers. A newer series is not guaranteed to be supported for longer, and between two series with the same end date the choice should rest on vendor support and driver coverage.
What your SoC vendor supports. If the vendor BSP does not offer the target series, the kernel decision becomes a supplier decision. We compared the options in vendor BSP versus mainline kernel.
How your kernel tree relates to upstream. Many vendor BSPs do not share version-control history with the upstream stable tree. If the vendor delivered a source archive or a single squashed import, the migration is a port rather than a merge, and the estimate should say so.
Out-of-tree drivers and private patches. List every one, with its owner. Each must be rewritten and re-tested against the new series.
Re-qualification. For a certified product, the testing and documentation effort usually exceeds the engineering effort. Plan the kernel upgrade into a release that already carries a qualification cycle, rather than as a separate event.
How much of the change you actually build. No team needs to review every upstream change. Grouping a year of 6.1 fixes by subsystem name puts 15.6% of them in areas a headless industrial device does not build, such as wireless, network file systems, desktop graphics and virtualisation, and that is a lower bound: scoping to the files your own configuration compiles removes far more.
How security will be tracked afterwards. Decide who reads CVE records for your series. When negotiating with a BSP supplier, ask separately whether they will deliver fixes and whether they will issue identifiers, because a supplier can do the first without the second.

A quick check of where your product stands

Start by finding the exact kernel the product runs, on the board, and the upstream version the BSP source started from, in the BSP tree. Look both up in the longterm table on kernel.org.

raghu@techveda.org:~$ cat /proc/version
raghu@techveda.org:~$ make kernelversion

To see how far behind the tip of its own series the product is, add the stable tree to a kernel repository and count the changes between the release you started from and the latest one. The example uses 6.1.158 and 6.1.191; replace them with your own versions. If your BSP does not share history with upstream, this measures what the series has received since your base version rather than your own tree’s distance from it.

raghu@techveda.org:~$ git remote add stable https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
raghu@techveda.org:~$ git fetch stable --tags
raghu@techveda.org:~$ git log --oneline --no-merges v6.1.158..v6.1.191 | wc -l

To check a specific defect, read its record in the kernel CVE repository. The “Affected and fixed versions” section lists each series separately.

raghu@techveda.org:~$ git clone https://git.kernel.org/pub/scm/linux/security/vulns.git
raghu@techveda.org:~$ cat vulns/cve/published/2026/CVE-2026-100073.mbox

Planning a kernel upgrade across a product line is part of what we teach in TECH VEDA’s Linux Systems Engineering training.

Key takeaways

A stale kernel is not a fixed cost. At end of life, fixes stop arriving, CVE identifiers stop being issued for defects found only in that series, and the eventual kernel upgrade keeps growing.
Every longterm series ends, and a newer series is not guaranteed to last longer, so compare projected end-of-life dates rather than version numbers.
Even a fully supported series never receives new drivers, so hardware changes will eventually force a kernel upgrade to a later series.
Treat point-release updates and series migration as separate decisions. Take the first as routine work, and start the second well before end of life.
Before upgrading, settle the destination series, vendor support, out-of-tree code, re-qualification and security tracking.

Was this worth your time?

Frequently asked questions

Our product works on its current kernel. Why change it?
Because the kernel’s situation changes even when the product does not. While the series is supported it keeps receiving fixes the product should take, and once it reaches end of life those fixes stop, as do new CVE identifiers for defects found only in that series. A working product on an unsupported kernel is one whose defects nobody upstream will fix or record any more.

Is it enough to take the latest point release of our series?
While the series is supported, yes, and it is the cheaper of the two decisions: the stable rules admit only bug fixes and new device IDs, and the change can be reversed. It is not enough once the series approaches end of life, or when the product needs a driver that only a later series contains.

Does a newer kernel series always come with a longer support period?
No. kernel.org sets a projected end-of-life date for each longterm series, usually starting at two years and extending some of them where industry interest supports it, so two neighbouring series can end on the same date. Compare the projected end-of-life dates rather than the version numbers.

What happens to CVEs for our series after it reaches end of life?
New ones stop being assigned for defects found only in that series. The kernel CVE documentation states that no CVEs will be assigned for an issue found in a version that the stable team is not actively supporting. Records already published remain valid, and defects in code shared with a supported series still receive records.

References

Raghu Bharadwaj

Founder, TECH VEDA — 20+ years teaching the Linux kernel, device drivers and embedded systems.

Follow on LinkedIn