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 <[email protected]>
Sent: Thursday, March 12, 2026 7:02 PM
To: Marko, Peter <[email protected]>; Deepak Rathore -X (deeratho - E
INFOCHIPS PRIVATE LIMITED at Cisco) <[email protected]>;
[email protected]
<[email protected]>
Cc: Viral Chavda (vchavda) <[email protected]>
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: [email protected] <openembedded-
>> [email protected]> On Behalf Of Deepak Rathore via
>> lists.openembedded.org
>> Sent: Thursday, March 12, 2026 9:46
>> To: [email protected]; Yoann Congal
>> <[email protected]>
>> Cc: Viral Chavda (vchavda) <[email protected]>
>> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#233241):
https://lists.openembedded.org/g/openembedded-core/message/233241
Mute This Topic: https://lists.openembedded.org/mt/118275693/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
