Inquiry Regarding Package Upgrade Approach vs. Manual CVE Fixes in LTS Releases

Inquiry Regarding Package Upgrade Approach vs. Manual CVE Fixes in LTS Releases

[Deepak Rathore -X (deeratho - E INFOCHIPS PRIVATE LIMITED at Cisco)]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

Hi Yoann,
I hope you are doing well.
I am currently working for Cisco where our team focuses primarily on:

  *   CVE fixing for OSS packages
  *   Package upgrades
  *   LTP execution and validation
  *
Package testing

As part of our work, we also submit CVE fix patches to the community from time to time whenever new vulnerabilities are reported.
I am reaching out to understand more about the list of packages that the OpenEmbedded community prefers to upgrade directly instead of applying manual CVE backport fixes within LTS releases. Having this information would help us align our internal workflows with the community strategy and avoid any duplication of effort.
Could you please share the details or point me to the relevant documentation or list that outlines this package-upgrade policy for LTS?
Thanks in advance for your support, and please let me know if any additional information is needed from my side.
Best regards,
Deepak Rathore

[-- Attachment #2: Type: text/html, Size: 4346 bytes --]

RE: Inquiry Regarding Package Upgrade Approach vs. Manual CVE Fixes in LTS Releases

[Marko, Peter]

Hello Deepak,
this was during last couple weeks and the decision is here:
https://lists.openembedded.org/g/openembedded-core/message/232562

Yoann,
It would be great if Yocto project would document this decision under following page:
https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS
I'm not sure who can do that.

Peter

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Deepak Rathore via
> lists.openembedded.org
> Sent: Thursday, March 12, 2026 9:46
> To: openembedded-core@lists.openembedded.org; Yoann Congal
> <yoann.congal@smile.fr>
> Cc: Viral Chavda (vchavda) <vchavda@cisco.com>
> Subject: [OE-core] Inquiry Regarding Package Upgrade Approach vs. Manual CVE
> Fixes in LTS Releases
> 
> Hi Yoann,
> I hope you are doing well.
> I am currently working for Cisco where our team focuses primarily on:
> 
> *	CVE fixing for OSS packages
> *	Package upgrades
> *	LTP execution and validation
> *
> 	Package testing
> 
> As part of our work, we also submit CVE fix patches to the community from time
> to time whenever new vulnerabilities are reported.
> I am reaching out to understand more about the list of packages that the
> OpenEmbedded community prefers to upgrade directly instead of applying
> manual CVE backport fixes within LTS releases. Having this information would help
> us align our internal workflows with the community strategy and avoid any
> duplication of effort.
> Could you please share the details or point me to the relevant documentation or
> list that outlines this package-upgrade policy for LTS?
> Thanks in advance for your support, and please let me know if any additional
> information is needed from my side.
> Best regards,
> Deepak Rathore

Re: Inquiry Regarding Package Upgrade Approach vs. Manual CVE Fixes in LTS Releases

[Yoann Congal]

On Thu Mar 12, 2026 at 9:58 AM CET, Peter Marko wrote:
> Hello Deepak,
> this was during last couple weeks and the decision is here:
> https://lists.openembedded.org/g/openembedded-core/message/232562
>
> Yoann,
> It would be great if Yocto project would document this decision under following page:
> https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS
> I'm not sure who can do that.

I will.

FYI, we are in the process of migrating this info to
docs.yoctoproject.org.  I initially planed to add this info there but
since it is needed now, I might as well add it in the wiki.

>
> Peter
>
>> -----Original Message-----
>> From: openembedded-core@lists.openembedded.org <openembedded-
>> core@lists.openembedded.org> On Behalf Of Deepak Rathore via
>> lists.openembedded.org
>> Sent: Thursday, March 12, 2026 9:46
>> To: openembedded-core@lists.openembedded.org; Yoann Congal
>> <yoann.congal@smile.fr>
>> Cc: Viral Chavda (vchavda) <vchavda@cisco.com>
>> Subject: [OE-core] Inquiry Regarding Package Upgrade Approach vs. Manual CVE
>> Fixes in LTS Releases
>> 
>> Hi Yoann,
>> I hope you are doing well.
>> I am currently working for Cisco where our team focuses primarily on:
>> 
>> *	CVE fixing for OSS packages
>> *	Package upgrades
>> *	LTP execution and validation
>> *
>> 	Package testing
>> 
>> As part of our work, we also submit CVE fix patches to the community from time
>> to time whenever new vulnerabilities are reported.
>> I am reaching out to understand more about the list of packages that the
>> OpenEmbedded community prefers to upgrade directly instead of applying
>> manual CVE backport fixes within LTS releases. Having this information would help
>> us align our internal workflows with the community strategy and avoid any
>> duplication of effort.
>> Could you please share the details or point me to the relevant documentation or
>> list that outlines this package-upgrade policy for LTS?

The policy for patch acceptance on stable is mostly documented here:
https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#Stable/LTS_Patch_Acceptance_Policies

As stated, "General version upgrades" are unacceptable but there is an
exception for "Changes to follow an upstream stable series or LTS that
aligns with the original release (based on compatibility)". The upstream
upgrade will, then, have to follow the same rules as our stable
branches:
* Security and CVE fixes
* Fixes for bugs
* No feature addition

From my point of view, the list of recipe cited in [0] are an
application of this exception.

[0]: Re: Recipes which should always be upgraded on stable branches
     https://lists.openembedded.org/g/openembedded-core/message/232562

In case that helps to make it more clear, here are example of recent
upgrades on scarthgap that fall into the same exception:
* bind: Upgrade 9.18.41 -> 9.18.44
* mobile-broadband-provider-info: upgrade 20240407 -> 20251101
* glibc: stable 2.39 branch updates
* ffmpeg: upgrade 6.1.3 -> 6.1.4
* ruby: Upgrade 3.3.5 -> 3.3.10

>> Thanks in advance for your support, and please let me know if any additional
>> information is needed from my side.
>> Best regards,
>> Deepak Rathore

Regards,
-- 
Yoann Congal
Smile ECS

Re: Inquiry Regarding Package Upgrade Approach vs. Manual CVE Fixes in LTS Releases

[Deepak Rathore -X (deeratho - E INFOCHIPS PRIVATE LIMITED at Cisco)]

[-- Attachment #1: Type: text/plain, Size: 6620 bytes --]

Hi Yoann, Peter,
Thank you for the detailed explanation. I’d like to share a few additional observations from our experience handling CVE remediation across multiple LTS branches. These examples illustrate why the scope for allowing package upgrades should not be restricted only to the recipes already listed.
Key Points & Use Cases
Use Case 1: When manual CVE backports effectively become full package upgrades:

  *   For several packages, fixing a single CVE requires cherry‑picking a long chain of dependent commits.
  *   This often means pulling in new files, refactored logic, and significant code from a newer upstream release.
  *   Although the version number remains unchanged, the resulting codebase becomes much closer to a newer upstream version—without the transparency of an actual upgrade.
  *   Such heavy backporting adds complexity and goes beyond the intended scope of stable/LTS maintenance.

Challenges with CVE detection on heavily modified codebases:

  *   When large portions of newer code are backported, CVE scanning tools still reference the old version number.
  *   This leads to scenarios where newly introduced upstream code may contain vulnerabilities that scanners cannot detect, because the version lineage no longer matches the real codebase.

Use Case 2: Vim  – Patch application blocked by binary test files:

  *
Consider another case of vim package, where package community increase minor version when they add one commit and increment the major version number where minor version number go beyond 2000.
  *
We also should do package upgrade for vim package to fix security issues because  it is kind of applying commits from vim package upstream
  *
There is one another example of vim package CVE: CVE‑2026‑28421
     *
Fixed commit: https://github.com/vim/vim/commit/65c1a143c331c886dc28888dd632708f953b4eb3
     *   The commit includes two .swp binary files used for updated tests (test_recover.vim).
     *   When cherry‑picking into LTS/stable, quilt fails in do_patch because binary artifacts cannot be applied cleanly.
     *   Dropping the test changes reduces coverage and weakens verification of the fix.
     *   In such cases, performing a package upgrade provides a cleaner, more reliable solution.

Use Case 3: When upstream provides no standalone fix—only a version upgrade:

  *   Some CVEs are fixed only via upstream package updates, with no standalone patch available.
  *   Example: MariaDB (CVE‑2026‑3494)
     *   Fix reference: https://github.com/microsoft/azurelinux/pull/16143
     *   The resolution involves upgrading MariaDB to version 10.11.16.
  *   When the upstream fix exists only in an updated version, upgrading the package is the only viable approach

Please share your thoughts on this.

Regards,
Deepak
________________________________
From: Yoann Congal <yoann.congal@smile.fr>
Sent: Thursday, March 12, 2026 7:02 PM
To: Marko, Peter <Peter.Marko@siemens.com>; Deepak Rathore -X (deeratho - E INFOCHIPS PRIVATE LIMITED at Cisco) <deeratho@cisco.com>; openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>
Cc: Viral Chavda (vchavda) <vchavda@cisco.com>
Subject: Re: Inquiry Regarding Package Upgrade Approach vs. Manual CVE Fixes in LTS Releases

On Thu Mar 12, 2026 at 9:58 AM CET, Peter Marko wrote:
> Hello Deepak,
> this was during last couple weeks and the decision is here:
> https://lists.openembedded.org/g/openembedded-core/message/232562
>
> Yoann,
> It would be great if Yocto project would document this decision under following page:
> https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS
> I'm not sure who can do that.

I will.

FYI, we are in the process of migrating this info to
docs.yoctoproject.org.  I initially planed to add this info there but
since it is needed now, I might as well add it in the wiki.

>
> Peter
>
>> -----Original Message-----
>> From: openembedded-core@lists.openembedded.org <openembedded-
>> core@lists.openembedded.org> On Behalf Of Deepak Rathore via
>> lists.openembedded.org
>> Sent: Thursday, March 12, 2026 9:46
>> To: openembedded-core@lists.openembedded.org; Yoann Congal
>> <yoann.congal@smile.fr>
>> Cc: Viral Chavda (vchavda) <vchavda@cisco.com>
>> Subject: [OE-core] Inquiry Regarding Package Upgrade Approach vs. Manual CVE
>> Fixes in LTS Releases
>>
>> Hi Yoann,
>> I hope you are doing well.
>> I am currently working for Cisco where our team focuses primarily on:
>>
>> *    CVE fixing for OSS packages
>> *    Package upgrades
>> *    LTP execution and validation
>> *
>>       Package testing
>>
>> As part of our work, we also submit CVE fix patches to the community from time
>> to time whenever new vulnerabilities are reported.
>> I am reaching out to understand more about the list of packages that the
>> OpenEmbedded community prefers to upgrade directly instead of applying
>> manual CVE backport fixes within LTS releases. Having this information would help
>> us align our internal workflows with the community strategy and avoid any
>> duplication of effort.
>> Could you please share the details or point me to the relevant documentation or
>> list that outlines this package-upgrade policy for LTS?

The policy for patch acceptance on stable is mostly documented here:
https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#Stable/LTS_Patch_Acceptance_Policies

As stated, "General version upgrades" are unacceptable but there is an
exception for "Changes to follow an upstream stable series or LTS that
aligns with the original release (based on compatibility)". The upstream
upgrade will, then, have to follow the same rules as our stable
branches:
* Security and CVE fixes
* Fixes for bugs
* No feature addition

From my point of view, the list of recipe cited in [0] are an
application of this exception.

[0]: Re: Recipes which should always be upgraded on stable branches
     https://lists.openembedded.org/g/openembedded-core/message/232562

In case that helps to make it more clear, here are example of recent
upgrades on scarthgap that fall into the same exception:
* bind: Upgrade 9.18.41 -> 9.18.44
* mobile-broadband-provider-info: upgrade 20240407 -> 20251101
* glibc: stable 2.39 branch updates
* ffmpeg: upgrade 6.1.3 -> 6.1.4
* ruby: Upgrade 3.3.5 -> 3.3.10

>> Thanks in advance for your support, and please let me know if any additional
>> information is needed from my side.
>> Best regards,
>> Deepak Rathore

Regards,
--
Yoann Congal
Smile ECS


[-- Attachment #2: Type: text/html, Size: 14401 bytes --]

Re: [OE-core] Inquiry Regarding Package Upgrade Approach vs. Manual CVE Fixes in LTS Releases

[Richard Purdie]

On Thu, 2026-03-12 at 08:45 +0000, Deepak Rathore via lists.openembedded.org wrote:
> I am currently working for Cisco where our team focuses primarily on:
>  * CVE fixing for OSS packages
>  * Package upgrades
>  * LTP execution and validation

I would note that we're going to have to drop support for LTP in the
next week before feature freeze.

Upstream have removed runltp and switched to kirk. We have no support
for this. I have repeatedly asked for help in switching but have not
received any, a such we likely need to remove ltp for the next LTS.

Cheers,

Richard

Re: [OE-core] Inquiry Regarding Package Upgrade Approach vs. Manual CVE Fixes in LTS Releases

[Alexander Kanavin]

On Mon, 16 Mar 2026 at 10:39, Deepak Rathore via
lists.openembedded.org <deeratho=cisco.com@lists.openembedded.org>
wrote:
> When the upstream fix exists only in an updated version, upgrading the package is the only viable approach
>
> Please share your thoughts on this.

My thought, and I've expressed it many, many times before, is that you
should learn to upgrade your products to new Yocto releases, instead
of assuming that they can stay on the same LTS release for their
entire lifecycle. Yes it's difficult and costly and adds risk. You
need to set up bulletproof, automated testing and qa pipelines. You
need to convince management. But I firmly believe that's the only way
you can avoid hitting those nasty CVEs that can't be backported.

vim upstream is a special kind of madness. They file CVEs for pretty
much any potential security issue they find, and I have this feeling
that people want to address vim CVEs not to improve actual product
security, but merely to silence the CVE tooling they run. Meanwhile,
there's plenty of potential security issues fixed in various other
components that don't even get a CVE, they're simply released quietly
in a new version. I feel that product security is better addressed by
simply staying close to upstream. Unfortunately a whole industry has
developed around CVE backports, and I am aware this is a minority
opinion.

LTS upgrade policy is not going to change. LTS makes the promise of
stability, and unfortunately it does come at the expense of security,
or at least is pushes the security issue down to product developers
from yocto upstream. That promise can't be broken.

Alex

Re: [OE-core] Inquiry Regarding Package Upgrade Approach vs. Manual CVE Fixes in LTS Releases

[Paul Barker]

[-- Attachment #1: Type: text/plain, Size: 4193 bytes --]

On Mon, 2026-03-16 at 09:39 +0000, Deepak Rathore via
lists.openembedded.org wrote:
> Hi Yoann, Peter,
> Thank you for the detailed explanation. I’d like to share a few additional observations from our experience handling CVE remediation across multiple LTS branches. These examples illustrate why the scope for allowing package upgrades should not be restricted only to the recipes already listed.
> Key Points & Use Cases
> Use Case 1: When manual CVE backports effectively become full package upgrades:
> 
>   *   For several packages, fixing a single CVE requires cherry‑picking a long chain of dependent commits.
>   *   This often means pulling in new files, refactored logic, and significant code from a newer upstream release.
>   *   Although the version number remains unchanged, the resulting codebase becomes much closer to a newer upstream version—without the transparency of an actual upgrade.
>   *   Such heavy backporting adds complexity and goes beyond the intended scope of stable/LTS maintenance.
> 
> Challenges with CVE detection on heavily modified codebases:
> 
>   *   When large portions of newer code are backported, CVE scanning tools still reference the old version number.
>   *   This leads to scenarios where newly introduced upstream code may contain vulnerabilities that scanners cannot detect, because the version lineage no longer matches the real codebase.

Hi Deepak,

You mention that this is based on your experience handling CVE
remediation. Could you share a specific case where this has happened?

> Use Case 2: Vim  – Patch application blocked by binary test files:
> 
>   *
> Consider another case of vim package, where package community increase minor version when they add one commit and increment the major version number where minor version number go beyond 2000.
>   *
> We also should do package upgrade for vim package to fix security issues because  it is kind of applying commits from vim package upstream
>   *
> There is one another example of vim package CVE: CVE‑2026‑28421
>      *
> Fixed commit: https://github.com/vim/vim/commit/65c1a143c331c886dc28888dd632708f953b4eb3
>      *   The commit includes two .swp binary files used for updated tests (test_recover.vim).
>      *   When cherry‑picking into LTS/stable, quilt fails in do_patch because binary artifacts cannot be applied cleanly.
>      *   Dropping the test changes reduces coverage and weakens verification of the fix.
>      *   In such cases, performing a package upgrade provides a cleaner, more reliable solution.

Please share the error message generated by quilt, this may be something
we need to look in to so that we can support patches that add such
binary test data. If this doesn't work, we may be able to add the new
.swp files to layer itself (under meta/recipes-support/vim/files/) and
to SRC_URI so that the patch file does not need to include them.

> Use Case 3: When upstream provides no standalone fix—only a version upgrade:
> 
>   *   Some CVEs are fixed only via upstream package updates, with no standalone patch available.
>   *   Example: MariaDB (CVE‑2026‑3494)
>      *   Fix reference: https://github.com/microsoft/azurelinux/pull/16143
>      *   The resolution involves upgrading MariaDB to version 10.11.16.
>   *   When the upstream fix exists only in an updated version, upgrading the package is the only viable approach

Some CVEs are difficult to fix, and distributions may choose not to take
invasive patches for them if the severity is low. For example in RHEL,
the fix for this issue is currently deferred
(https://access.redhat.com/security/cve/cve-2026-3494).

If you are concerned about this particular CVE, then you need to discuss
this on the openembedded-devel mailing list as the mariadb recipe is in
the meta-oe layer.

> Please share your thoughts on this.

This email has characteristics that suggest to me that it might be
generated by AI/LLM. If that is the case, please remember to reduce the
verbosity of the LLM output so that it is easier to read, and to confirm
that its responses are accurate.

Thanks,

-- 
Paul Barker


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]