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
signature.asc
Description: This is a digitally signed message part
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#233249): https://lists.openembedded.org/g/openembedded-core/message/233249 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]] -=-=-=-=-=-=-=-=-=-=-=-
