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

[Paul Barker <paul@pbarker.dev>]

[-- 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 --]