What the Yocto LTS Covers, and What It Does Not

Most embedded teams can name the Yocto release their product is built on and the date its support ends. Far fewer can name the recipe that builds the kernel inside the image, or say which organisation has committed to patching it. Those are different questions, and only the second one decides whether a security fix reaches your device. The Yocto LTS answers it clearly and in writing for one specific kernel. For the kernel most products actually ship, it does not answer it at all.

So it is worth drawing the line precisely: what the Yocto LTS covers, what it does not, and how to tell which side you are standing on.

A note on scope before we start. Where this article says the Yocto LTS supports something, it means the components named in the Yocto Project’s published LTS policy. That policy does not automatically extend to vendor layers, a vendor BSP kernel, proprietary drivers or firmware, custom recipes, or your own product image. Every lifecycle date below was checked on 4 September 2026, and the volatile ones are marked as projections where the source calls them that.

What the Yocto LTS covers

Start with the covered side, because it is more generous than most teams assume and because the confusion begins with two dates that are published by two different projects and never printed side by side.

Yocto Project 6.0 “Wrynose”, the current Yocto LTS, was announced in May 2026 as a Long Term Support series “supported until April 2030” — four fresh years, and the Yocto releases wiki says four years is now the plan for future LTS releases. Among the headline features of that release is Linux kernel 6.18 LTS. Set the two dates side by side:

For sixteen months, a team on the current Yocto LTS is inside its release support window while the upstream branch its kernel came from has passed its projected end of life. The obvious inference is that the kernel goes unmaintained for those sixteen months. That inference is wrong, and the Yocto Project has published why — on two wiki pages rather than in the release announcement, which is why it is easy to miss.

The kernel page states it directly: in terms of support, the linux-yocto recipes are treated the same as every other recipe in a release, and are supported for the life of that release and its corresponding stable updates. The stable and LTS policy then sets out what a stable or LTS branch will accept: security and CVE fixes, fixes for bugs, and changes that follow an upstream stable or LTS series aligned with the original release, on a compatibility basis. General version upgrades, new features and ABI or API breakage are not accepted.

Read together, those two statements say the linux-yocto recipe stays in scope for security fixes until April 2030, not until December 2028. What changes at the upstream end-of-life date is not whether the recipe is in scope but where its fixes come from: while 6.18 has a live stable series there is a stream to follow, and after that a fix has to reach the branch through the CVE and bug-fix route instead.

So on the covering side the answer is clear and it is written down: the recipe is inside the release, the release is supported for four years, and security fixes are an accepted class of change for the whole of it.

What it does not cover

Two things fall outside that commitment, and they are different in kind. The first is a limit on what the policy is. The second is a limit on what it applies to.

Be precise about what that policy is, though, because it is easy to read as more than it says. It is a patch acceptance policy. It tells you which changes an LTS branch will take, and which it refuses: general version upgrades, new features, and ABI or API breakage. It does not promise that somebody will find, backport and test every kernel CVE for you once the upstream stable series has stopped producing them. The branch stays open to the fix; the fix still has to be produced. For most of the release’s life that work is carried by the upstream stable stream. In the last sixteen months the branch is still open to fixes, but the source that was supplying most of them has stopped.

So the arithmetic stands and the alarming reading of it does not. Which raises the question that actually decides your exposure, and it is not about dates at all.

The second limit is the one that decides whether any of this reaches your product.

The same policy page that lists acceptable patches also names the layers it applies to. The Yocto LTS covers bitbake, OE-Core, meta-yocto and yocto-docs. It states that the project LTS does not cover meta-mingw, meta-gplv2 or vendor layers, and adds that other layers can and will have their own LTS processes. The linux-yocto recipes live in OE-Core, at openembedded-core/meta/recipes-kernel/linux/, which is precisely why the support statement above applies to them. Note also that the coverage is defined as a list of components rather than as whatever happens to be inside poky, so the layer reorganisation of recent releases does not change it.

Now hold that against what a shipped product usually builds. Vendor BSPs generally ship and select their own kernel recipe rather than the reference one: linux-imx from meta-freescale, a linux-ti-staging recipe from meta-ti, and similar arrangements in the layers for other SoC families, each setting itself as the preferred provider for virtual/kernel. Many teams then fork that recipe into a layer of their own, carrying out-of-tree drivers and sometimes proprietary binary modules. Every one of those sits outside the four components the Yocto LTS covers. The Yocto LTS date on your plan describes the build system and the recipes in OE-Core. It does not describe the kernel you actually boot.

One inference to avoid here, because it is easy to make. A vendor BSP kernel is not interchangeable with the linux-yocto recipe merely because both derive from the same upstream release line. Two recipes built on 6.18 can carry different patch stacks, different configuration fragments, different release processes, different hardware validation, and different maintenance owners. Sharing an upstream version number tells you almost nothing about who fixes your CVEs.

That is the real finding, and it is more useful than the sixteen months. The Yocto Project publishes a clear maintenance commitment; the risk is that teams read it as covering a kernel it was never scoped to cover.

Outside the Yocto LTS is not the same as unsupported

The same reading applies to the branch names in a vendor repository. NXP’s i.MX kernel tree, checked on 4 September 2026, carries lf- branches going back to lf-5.10.y, and among the current ones both lf-6.12.y and lf-6.18.y. A team on lf-6.12.y might reasonably assume that migrating to lf-6.18.y extends the time before the next uplift. It does not. Both are cut from kernels projected to stop in December 2028. There is a good reason to make that move anyway, and it is a different one: on that same date, only lf-6.18.y was taking commits. Read that as a signal rather than a verdict — vendors tie a kernel branch to a BSP release and support it for as long as they support that release, so a quiet branch may still receive a patch drop, and the question that settles it is whether the vendor has declared that BSP release end of life, not what the commit log did last month. That date, not the Yocto LTS date, is the one your fixes actually arrive on. We covered how to judge whether a vendor branch is alive at all in our piece on spotting an SoC whose kernel support has already lapsed; this is the calendar layer above that.

Being outside the Yocto LTS is not the same as being unsupported, and it would be wrong to leave that impression. The Yocto LTS policy itself says other layers can and will have their own LTS processes, and the good ones do. meta-freescale publishes a maintenance policy stating that its LTS branches are maintained for the duration of the Yocto Project’s LTS support, prioritising bug fixes, CVE updates and BSP backports — and, more usefully than that summary suggests, it publishes two dates per branch. Its scarthgap branch is given as maintained until April 2028 for bug fixes but only until April 2026 for BSP backports. Two years separate them.

That split is worth carrying into your own plan, because it is not a distinction anyone makes for you in a design review. A branch can be receiving CVE fixes while no longer accepting new board support, which is exactly the state in which a late hardware revision becomes expensive. Go and read your own vendor layer’s README or about page and find out whether it publishes one date or two.

Find out which side your kernel is on

Everything above turns on one fact about your own build, so establish it before you plan anything else. This is a two-minute check in your build directory and it settles who owns the maintenance.

raghu@techveda.org:~$ bitbake -e virtual/kernel | grep '^PN='
PN="linux-yocto"
raghu@techveda.org:~$ bitbake -e virtual/kernel | grep '^FILE='

PN names the recipe currently providing the kernel. The value shown above is what a reference machine returns; on a vendor BSP expect linux-imx, linux-fslc-imx, a TI recipe or another vendor name instead, and that difference is the whole point of running it. FILE then gives the full path of that recipe, and the leading layer directory tells you which layer provides it: meta/recipes-kernel/linux/ means OE-Core and the Yocto LTS commitment applies, while meta-freescale/recipes-kernel/linux/ or a path inside your own layer means you are outside it. Treat that as an indicator of who maintains the recipe rather than as a formal support statement — the layer path is where you start asking, not the answer.

Confirm what is selecting it with the preferred-provider setting, which is what a BSP layer sets to point the build at its own kernel. Give the command a target: a bare bitbake -e with nothing to expand against is unreliable, and the variable is frequently set with a machine or distro override that only shows up once the configuration has been resolved for something concrete.

raghu@techveda.org:~$ bitbake -e virtual/kernel | grep PREFERRED_PROVIDER_virtual/kernel
raghu@techveda.org:~$ bitbake -e core-image-minimal | grep PREFERRED_PROVIDER_virtual/kernel

For a fuller picture, read conf/bblayers.conf to see which layers are in the build at all — but be careful which mechanism you credit for what, because two different ones are at work and they are easy to conflate. BBFILE_PRIORITY, set in a layer’s conf/layer.conf, decides which layer wins when two layers carry a recipe of the same name, and it holds regardless of recipe version. It does not choose your kernel provider: the documentation states that layer priority does not affect the precedence order of .conf files. PREFERRED_PROVIDER_virtual/kernel is a configuration variable, so a layer later in the BBLAYERS list overrides an earlier assignment, and a machine or distro configuration parsed later overrides that in turn. In short: BBLAYERS order and your machine configuration settle which recipe provides the kernel, and layer priority settles which layer’s copy of that recipe is used.

Run this once per product and write the answer next to the dates. A team that cannot say which layer supplies its kernel cannot say who fixes its CVEs, and that is a more immediate problem than anything happening in 2029.

Once you know who owns the kernel, the remaining work is to write down every lifecycle date your product depends on and give each one an owner. That is a separate exercise with its own tables, and it is covered in the companion article on the support clocks an embedded product actually runs on.

Key takeaways

• The line runs between components, not releases: the Yocto LTS covers bitbake, OE-Core, meta-yocto and yocto-docs, and excludes vendor layers by name — which is where most shipped products get their kernel.
• The Yocto Project states that linux-yocto recipes are supported for the life of the release and its stable updates, and its LTS policy accepts security and CVE fixes.
• Read that as an acceptance policy, not a maintenance guarantee. It says what an LTS branch will take, not that somebody will produce every fix once the upstream stable series has stopped.
• Run bitbake -e virtual/kernel and read PN and FILE. The leading layer directory in that path tells you where to ask about maintenance.
• Sharing an upstream version number means nothing about maintenance. A vendor recipe on 6.18 and linux-yocto on 6.18 are separate maintenance objects with separate owners.
• Outside the Yocto LTS is not the same as unsupported. meta-freescale publishes per-branch dates and gives an earlier date for BSP backports than for bug fixes. Find your layer’s statement and record both.

Frequently asked questions

Does kernel.org end of life mean Yocto stops shipping kernel fixes?
Not for linux-yocto. The Yocto Project states that its linux-yocto recipes are supported for the life of the release and its corresponding stable updates, and its LTS policy accepts security and CVE fixes as well as compatible backports. Note the limit of that: it is a patch acceptance policy, so it commits the branch to taking a qualifying fix rather than committing anyone to producing one after the upstream stable series ends.

What exactly does the Yocto LTS cover?
Bitbake, OE-Core, meta-yocto and yocto-docs. The policy states that it does not cover meta-mingw, meta-gplv2 or vendor layers, and that other layers can and will have their own LTS processes. The linux-yocto recipes live in OE-Core, which is why the support statement reaches them.

How do I find out which recipe provides my kernel?
Run bitbake -e virtual/kernel in your build directory and read the PN and FILE values. PN is the recipe name and FILE is its path; the leading layer directory in that path tells you whether you are on OE-Core, a vendor layer, or a layer of your own. Cross-check with conf/bblayers.conf and the effective PREFERRED_PROVIDER_virtual/kernel, expanded against a real target rather than a bare bitbake -e.

Do vendor layers publish maintenance dates at all?
Some do. meta-freescale publishes a maintenance policy stating that its LTS branches are maintained for the duration of the Yocto Project’s LTS support, and it gives per-branch dates that separate bug fixes from BSP backports — its scarthgap branch is listed as maintained until April 2028 for bug fixes but only until April 2026 for BSP backports. Check your own layer’s README or about page rather than assuming either way.

Further reading

• Yocto Project — Stable Release and LTS (patch acceptance policy and covered layers)
• Yocto Project — Linux Yocto (linux-yocto version lifecycle and support)
• meta-freescale — maintenance policy and per-branch support dates
• The Linux Kernel Archives — Active kernel releases
• Yocto Project 6.0 “Wrynose” release announcement
• Yocto Project — Releases and support levels