[PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517

[PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517

[Peter Marko]

From: Peter Marko <peter.marko@siemens.com>

These CVEs are for sudo-rs, not sudo.
It can be easily deducted from first word in NVD descripotion.
Also cvelistV5 product is "sudo-re".

It looks line that new version of sbom-cve-check matches product with
startsWith instead of equals?

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 meta/recipes-extended/sudo/sudo_1.9.17p2.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-extended/sudo/sudo_1.9.17p2.bb b/meta/recipes-extended/sudo/sudo_1.9.17p2.bb
index d6ee881f8c..12f81c5d4a 100644
--- a/meta/recipes-extended/sudo/sudo_1.9.17p2.bb
+++ b/meta/recipes-extended/sudo/sudo_1.9.17p2.bb
@@ -60,3 +60,6 @@ RDEPENDS:${PN} += "${SUDO_PACKAGES}"
 
 FILES:${PN}-sudo = "${bindir}/sudo ${bindir}/sudoedit"
 FILES:${PN}-lib = "${localstatedir} ${libexecdir} ${sysconfdir} ${libdir} ${nonarch_libdir}"
+
+CVE_STATUS[CVE-2025-64170] = "cpe-incorrect: this CVE is for sudo-rs"
+CVE_STATUS[CVE-2025-64517] = "cpe-incorrect: this CVE is for sudo-rs"

[PATCH 2/6] cargo: set status of CVE-2023-40030

[Peter Marko]

From: Peter Marko <peter.marko@siemens.com>

sbom-cve-check has problem matching version 1.72.
It works only if cvelistV5 is modified to indicate 1.72.0.

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 meta/recipes-devtools/rust/cargo_1.94.1.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/rust/cargo_1.94.1.bb b/meta/recipes-devtools/rust/cargo_1.94.1.bb
index fc41a19a25..36ec346113 100644
--- a/meta/recipes-devtools/rust/cargo_1.94.1.bb
+++ b/meta/recipes-devtools/rust/cargo_1.94.1.bb
@@ -83,3 +83,5 @@ RUSTLIB:append:class-nativesdk = " -L ${STAGING_DIR_HOST}/${SDKPATHNATIVE}/usr/l
 RUSTLIB_DEP:class-nativesdk = ""
 
 BBCLASSEXTEND = "native nativesdk"
+
+CVE_STATUS[CVE-2023-40030] = "fixed-version: fixed since 1.72"

[PATCH 3/6] cargo: set CVE_PRODUCT

[Peter Marko]

From: Peter Marko <peter.marko@siemens.com>

This removes mediawiki:cargo CVEs from CVE metrics.
* CVE-2026-39837, CVE-2026-39839, CVE-2026-39840, CVE-2026-39841

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 meta/recipes-devtools/rust/cargo_1.94.1.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/rust/cargo_1.94.1.bb b/meta/recipes-devtools/rust/cargo_1.94.1.bb
index 36ec346113..f16688fc76 100644
--- a/meta/recipes-devtools/rust/cargo_1.94.1.bb
+++ b/meta/recipes-devtools/rust/cargo_1.94.1.bb
@@ -17,6 +17,8 @@ require rust-snapshot.inc
 S = "${RUSTSRC}/src/tools/cargo"
 CARGO_VENDORING_DIRECTORY = "${RUSTSRC}/vendor"
 
+CVE_PRODUCT = "rust-lang:cargo"
+
 inherit cargo pkgconfig
 
 DEBUG_PREFIX_MAP += "-ffile-prefix-map=${RUSTSRC}/vendor=${TARGET_DBGSRC_DIR}"

[PATCH 4/6] git: set status of 5 CVEs

[Peter Marko]

From: Peter Marko <peter.marko@siemens.com>

It is unclear why entries in cvelistV5 cause these CVEs to appear in CVE
reports.
There is one which should also not be shown per listed CPEs, however it
does not have a patch, so it's not added to the list - CVE-2024-52005.
The others are set to fixed with version based on which .0 release
included patch mentioned in Debian security tracker for respective CVE.

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 meta/recipes-devtools/git/git_2.53.0.bb | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-devtools/git/git_2.53.0.bb b/meta/recipes-devtools/git/git_2.53.0.bb
index 5fe1767e28..5169e93931 100644
--- a/meta/recipes-devtools/git/git_2.53.0.bb
+++ b/meta/recipes-devtools/git/git_2.53.0.bb
@@ -171,3 +171,9 @@ EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
 EXTRA_OEMAKE += "NO_GETTEXT=1"
 
 SRC_URI[tarball.sha256sum] = "429dc0f5fe5f14109930cdbbb588c5d6ef5b8528910f0d738040744bebdc6275"
+
+CVE_STATUS[CVE-2024-32002] = "fixed version: fixed since v2.46.0"
+CVE_STATUS[CVE-2024-50349] = "fixed version: fixed since v2.49.0"
+CVE_STATUS[CVE-2024-52006] = "fixed version: fixed since v2.49.0"
+CVE_STATUS[CVE-2025-48385] = "fixed version: fixed since v2.51.0"
+CVE_STATUS[CVE-2025-48386] = "fixed version: fixed since v2.51.0"

[PATCH 5/6] ovmf: set status for 7 CVEs

[Peter Marko]

From: Peter Marko <peter.marko@siemens.com>

These reappeared after last update of sbom-cve-check tooling.
"fixed-in" release was determined by following links in Debian CVE
reports except CVE-2025-2295 which was taken from Yocto master CVE
patch.

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 meta/recipes-core/ovmf/ovmf_git.bb | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb
index d731bca7f2..19bcc4a96f 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -48,6 +48,13 @@ CVE_STATUS[CVE-2019-14575] = "fixed-version: The CPE in the NVD database doesn't
 CVE_STATUS[CVE-2019-14586] = "fixed-version: The CPE in the NVD database doesn't reflect correctly the vulnerable versions."
 CVE_STATUS[CVE-2019-14587] = "fixed-version: The CPE in the NVD database doesn't reflect correctly the vulnerable versions."
 CVE_STATUS[CVE-2024-1298] = "fixed-version: fixed since edk2-stable202405"
+CVE_STATUS[CVE-2024-38796] = "fixed-version: fixed since edk2-stable202411"
+CVE_STATUS[CVE-2024-38797] = "fixed-version: fixed since edk2-stable202502"
+CVE_STATUS[CVE-2024-38798] = "fixed-version: fixed since edk2-stable202511"
+CVE_STATUS[CVE-2024-38805] = "fixed-version: fixed since edk2-stabe202508"
+CVE_STATUS[CVE-2025-2295] = "fixed-version: fixed since edk2-stable202505"
+CVE_STATUS[CVE-2025-2296] = "fixed-version: fixed since edk2-stable202505"
+CVE_STATUS[CVE-2025-3770] = "fixed-version: fixed since edk2-stable202508"
 
 inherit deploy
 

[PATCH 6/6] ffmpeg: set status for 5 CVEs

[Peter Marko]

From: Peter Marko <peter.marko@siemens.com>

These reappeared after update of sbom-cve-check tooling.
Fixed version found by links from Debian security tracker.

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb b/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
index 7bb7de3d25..9780abe184 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
@@ -176,6 +176,11 @@ CVE_STATUS_GROUPS = "CVE_STATUS_WRONG_CPE"
 CVE_STATUS_WRONG_CPE = "CVE-2023-51791 CVE-2023-51793 CVE-2023-51794 CVE-2023-51795 CVE-2023-51796 CVE-2023-51797 CVE-2023-51798 CVE-2025-22921"
 CVE_STATUS_WRONG_CPE[status] = "fixed-version: these CVEs are fixed in used version"
 
+CVE_STATUS[CVE-2022-2566] = "fixed-version: these CVEs are fixed since v5.1.1"
+CVE_STATUS[CVE-2025-9951] = "fixed-version: these CVEs are fixed since v8.0"
 CVE_STATUS[CVE-2025-25468] = "fixed-version: these CVEs are fixed since v8.0"
 CVE_STATUS[CVE-2025-25469] = "fixed-version: these CVEs are fixed since v8.0"
 CVE_STATUS[CVE-2025-12343] = "fixed-version: this CVE are fixed since v8.0"
+CVE_STATUS[CVE-2025-59729] = "fixed-version: this CVE are fixed since v8.0"
+CVE_STATUS[CVE-2025-59730] = "fixed-version: this CVE are fixed since v8.0"
+CVE_STATUS[CVE-2025-69693] = "fixed-version: this CVE are fixed since v8.1"

Re: [PATCH 6/6] ffmpeg: set status for 5 CVEs

[Benjamin Robin]

Hello Peter,

On Sunday, April 26, 2026 at 8:50 PM, Peter Marko wrote:
> From: Peter Marko <peter.marko@siemens.com>
> 
> These reappeared after update of sbom-cve-check tooling.
> Fixed version found by links from Debian security tracker.
> 
> Signed-off-by: Peter Marko <peter.marko@siemens.com>
> ---
>  meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb b/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
> index 7bb7de3d25..9780abe184 100644
> --- a/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
> @@ -176,6 +176,11 @@ CVE_STATUS_GROUPS = "CVE_STATUS_WRONG_CPE"
>  CVE_STATUS_WRONG_CPE = "CVE-2023-51791 CVE-2023-51793 CVE-2023-51794 CVE-2023-51795 CVE-2023-51796 CVE-2023-51797 CVE-2023-51798 CVE-2025-22921"
>  CVE_STATUS_WRONG_CPE[status] = "fixed-version: these CVEs are fixed in used version"
>  
> +CVE_STATUS[CVE-2022-2566] = "fixed-version: these CVEs are fixed since v5.1.1"
> +CVE_STATUS[CVE-2025-9951] = "fixed-version: these CVEs are fixed since v8.0"
>  CVE_STATUS[CVE-2025-25468] = "fixed-version: these CVEs are fixed since v8.0"
>  CVE_STATUS[CVE-2025-25469] = "fixed-version: these CVEs are fixed since v8.0"
>  CVE_STATUS[CVE-2025-12343] = "fixed-version: this CVE are fixed since v8.0"
> +CVE_STATUS[CVE-2025-59729] = "fixed-version: this CVE are fixed since v8.0"
> +CVE_STATUS[CVE-2025-59730] = "fixed-version: this CVE are fixed since v8.0"

> +CVE_STATUS[CVE-2025-69693] = "fixed-version: this CVE are fixed since v8.1"

Why the CVE-2025-69693 is marked has fixed?

It is affecting the version 8.0.1 which is the current version of the recipe,
as reported by NVD:
https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2025-69693

{ vulnerable: true, criteria: "cpe:2.3:a:ffmpeg:ffmpeg:8.0.1:*:*:*:*:*:*:*", 
  matchCriteriaId: "7F5CACA2-6FB6-4D6D-92D0-C9FF0E7CDB14" }

I did not investigate in which version this CVE was fixed.

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

RE: [PATCH 6/6] ffmpeg: set status for 5 CVEs

[Marko, Peter]

> -----Original Message-----
> From: Benjamin Robin <benjamin.robin@bootlin.com>
> Sent: Monday, April 27, 2026 9:45 AM
> To: openembedded-core@lists.openembedded.org; Marko, Peter (FT D EU SK
> BFS1) <Peter.Marko@siemens.com>
> Subject: Re: [PATCH 6/6] ffmpeg: set status for 5 CVEs
> 
> Hello Peter,
> 
> On Sunday, April 26, 2026 at 8:50 PM, Peter Marko wrote:
> > From: Peter Marko <peter.marko@siemens.com>
> >
> > These reappeared after update of sbom-cve-check tooling.
> > Fixed version found by links from Debian security tracker.
> >
> > Signed-off-by: Peter Marko <peter.marko@siemens.com>
> > ---
> >  meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb b/meta/recipes-
> multimedia/ffmpeg/ffmpeg_8.0.1.bb
> > index 7bb7de3d25..9780abe184 100644
> > --- a/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
> > +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
> > @@ -176,6 +176,11 @@ CVE_STATUS_GROUPS =
> "CVE_STATUS_WRONG_CPE"
> >  CVE_STATUS_WRONG_CPE = "CVE-2023-51791 CVE-2023-51793 CVE-
> 2023-51794 CVE-2023-51795 CVE-2023-51796 CVE-2023-51797 CVE-2023-
> 51798 CVE-2025-22921"
> >  CVE_STATUS_WRONG_CPE[status] = "fixed-version: these CVEs are fixed in
> used version"
> >
> > +CVE_STATUS[CVE-2022-2566] = "fixed-version: these CVEs are fixed since
> v5.1.1"
> > +CVE_STATUS[CVE-2025-9951] = "fixed-version: these CVEs are fixed since
> v8.0"
> >  CVE_STATUS[CVE-2025-25468] = "fixed-version: these CVEs are fixed since
> v8.0"
> >  CVE_STATUS[CVE-2025-25469] = "fixed-version: these CVEs are fixed since
> v8.0"
> >  CVE_STATUS[CVE-2025-12343] = "fixed-version: this CVE are fixed since
> v8.0"
> > +CVE_STATUS[CVE-2025-59729] = "fixed-version: this CVE are fixed since
> v8.0"
> > +CVE_STATUS[CVE-2025-59730] = "fixed-version: this CVE are fixed since
> v8.0"
> 
> > +CVE_STATUS[CVE-2025-69693] = "fixed-version: this CVE are fixed since
> v8.1"
> 
> Why the CVE-2025-69693 is marked has fixed?
> 
> It is affecting the version 8.0.1 which is the current version of the recipe,
> as reported by NVD:
> https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2025-69693

Thanks for noticing.
I guess I just want to have the cleanup finally finished and didn't think about the current version too much, just that there is already a version with a fix out.
Will send a v2 shortly.

> 
> { vulnerable: true, criteria: "cpe:2.3:a:ffmpeg:ffmpeg:8.0.1:*:*:*:*:*:*:*",
>   matchCriteriaId: "7F5CACA2-6FB6-4D6D-92D0-C9FF0E7CDB14" }
> 
> I did not investigate in which version this CVE was fixed.
> 
> --
> Benjamin Robin, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 
> 

[PATCH v2] ffmpeg: set status for 4 CVEs

[Peter Marko]

From: Peter Marko <peter.marko@siemens.com>

These reappeared after update of sbom-cve-check tooling.
Fixed version found by links from Debian security tracker.

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb b/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
index 7bb7de3d25..b6d3ceb6dc 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
@@ -176,6 +176,10 @@ CVE_STATUS_GROUPS = "CVE_STATUS_WRONG_CPE"
 CVE_STATUS_WRONG_CPE = "CVE-2023-51791 CVE-2023-51793 CVE-2023-51794 CVE-2023-51795 CVE-2023-51796 CVE-2023-51797 CVE-2023-51798 CVE-2025-22921"
 CVE_STATUS_WRONG_CPE[status] = "fixed-version: these CVEs are fixed in used version"
 
+CVE_STATUS[CVE-2022-2566] = "fixed-version: these CVEs are fixed since v5.1.1"
+CVE_STATUS[CVE-2025-9951] = "fixed-version: these CVEs are fixed since v8.0"
 CVE_STATUS[CVE-2025-25468] = "fixed-version: these CVEs are fixed since v8.0"
 CVE_STATUS[CVE-2025-25469] = "fixed-version: these CVEs are fixed since v8.0"
 CVE_STATUS[CVE-2025-12343] = "fixed-version: this CVE are fixed since v8.0"
+CVE_STATUS[CVE-2025-59729] = "fixed-version: this CVE are fixed since v8.0"
+CVE_STATUS[CVE-2025-59730] = "fixed-version: this CVE are fixed since v8.0"

RE: [PATCH v2] ffmpeg: set status for 4 CVEs

[Marko, Peter]

Could you please take one this instead of the old version to master-next?

ffmpeg: set status for 5 CVEs
https://git.openembedded.org/openembedded-core/commit/?h=master-next&id=e941054f6f1381742a5af02c85f8174cc776a81f

Thanks,
  Peter

-----Original Message-----
From: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com> 
Sent: Monday, April 27, 2026 12:11 PM
To: openembedded-core@lists.openembedded.org
Cc: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
Subject: [PATCH v2] ffmpeg: set status for 4 CVEs

From: Peter Marko <peter.marko@siemens.com>

These reappeared after update of sbom-cve-check tooling.
Fixed version found by links from Debian security tracker.

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb b/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
index 7bb7de3d25..b6d3ceb6dc 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_8.0.1.bb
@@ -176,6 +176,10 @@ CVE_STATUS_GROUPS = "CVE_STATUS_WRONG_CPE"
 CVE_STATUS_WRONG_CPE = "CVE-2023-51791 CVE-2023-51793 CVE-2023-51794 CVE-2023-51795 CVE-2023-51796 CVE-2023-51797 CVE-2023-51798 CVE-2025-22921"
 CVE_STATUS_WRONG_CPE[status] = "fixed-version: these CVEs are fixed in used version"
 
+CVE_STATUS[CVE-2022-2566] = "fixed-version: these CVEs are fixed since v5.1.1"
+CVE_STATUS[CVE-2025-9951] = "fixed-version: these CVEs are fixed since v8.0"
 CVE_STATUS[CVE-2025-25468] = "fixed-version: these CVEs are fixed since v8.0"
 CVE_STATUS[CVE-2025-25469] = "fixed-version: these CVEs are fixed since v8.0"
 CVE_STATUS[CVE-2025-12343] = "fixed-version: this CVE are fixed since v8.0"
+CVE_STATUS[CVE-2025-59729] = "fixed-version: this CVE are fixed since v8.0"
+CVE_STATUS[CVE-2025-59730] = "fixed-version: this CVE are fixed since v8.0"

RE: [PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517

[Marko, Peter]

> -----Original Message-----
> From: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> Sent: Sunday, April 26, 2026 8:50 PM
> To: openembedded-core@lists.openembedded.org
> Cc: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> Subject: [PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517
> 
> From: Peter Marko <peter.marko@siemens.com>
> 
> These CVEs are for sudo-rs, not sudo.
> It can be easily deducted from first word in NVD descripotion.
> Also cvelistV5 product is "sudo-re".
> 
> It looks line that new version of sbom-cve-check matches product with
> startsWith instead of equals?

Benjamin, any idea about this topic?

> 
> Signed-off-by: Peter Marko <peter.marko@siemens.com>
> ---
>  meta/recipes-extended/sudo/sudo_1.9.17p2.bb | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/meta/recipes-extended/sudo/sudo_1.9.17p2.bb b/meta/recipes-
> extended/sudo/sudo_1.9.17p2.bb
> index d6ee881f8c..12f81c5d4a 100644
> --- a/meta/recipes-extended/sudo/sudo_1.9.17p2.bb
> +++ b/meta/recipes-extended/sudo/sudo_1.9.17p2.bb
> @@ -60,3 +60,6 @@ RDEPENDS:${PN} += "${SUDO_PACKAGES}"
> 
>  FILES:${PN}-sudo = "${bindir}/sudo ${bindir}/sudoedit"
>  FILES:${PN}-lib = "${localstatedir} ${libexecdir} ${sysconfdir} ${libdir}
> ${nonarch_libdir}"
> +
> +CVE_STATUS[CVE-2025-64170] = "cpe-incorrect: this CVE is for sudo-rs"
> +CVE_STATUS[CVE-2025-64517] = "cpe-incorrect: this CVE is for sudo-rs"

Re: [PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517

[Benjamin Robin]

On Sunday, April 26, 2026 at 9:17 PM, Marko, Peter wrote:
> 
> > -----Original Message-----
> > From: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> > Sent: Sunday, April 26, 2026 8:50 PM
> > To: openembedded-core@lists.openembedded.org
> > Cc: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> > Subject: [PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517
> > 
> > From: Peter Marko <peter.marko@siemens.com>
> > 
> > These CVEs are for sudo-rs, not sudo.
> > It can be easily deducted from first word in NVD descripotion.
> > Also cvelistV5 product is "sudo-re".
> > 
> > It looks line that new version of sbom-cve-check matches product with
> > startsWith instead of equals?
> 
> Benjamin, any idea about this topic?

Yes, sadly the CPE of sudo-rs is trifectatech:sudo.
Why this is the official CPE of sudo-rs, I don't know...

What it is happening:
 - From https://cveawg.mitre.org/api/cve/CVE-2025-64170
   we extract vendor and product name, then we look the products database
   which is built in sbom-cve-check.
 - The returned CPE are "memorysafety:sudo", "trifectatech:sudo"
 - Then we check if the CPE in the SBOM matches with these CPE.
   Currently sudo is declared as: *:sudo, which matches trifectatech:sudo.

The easy fix is to declare the proper CPE of sudo using CVE_PRODUCT,
which should be set to "sudo_project:sudo".

This behavior is documented here:
https://sbom-cve-check.readthedocs.io/en/latest/design.html#find-applicable-cve

> 
> > 
> > Signed-off-by: Peter Marko <peter.marko@siemens.com>
> > ---
> >  meta/recipes-extended/sudo/sudo_1.9.17p2.bb | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/meta/recipes-extended/sudo/sudo_1.9.17p2.bb b/meta/recipes-
> > extended/sudo/sudo_1.9.17p2.bb
> > index d6ee881f8c..12f81c5d4a 100644
> > --- a/meta/recipes-extended/sudo/sudo_1.9.17p2.bb
> > +++ b/meta/recipes-extended/sudo/sudo_1.9.17p2.bb
> > @@ -60,3 +60,6 @@ RDEPENDS:${PN} += "${SUDO_PACKAGES}"
> > 
> >  FILES:${PN}-sudo = "${bindir}/sudo ${bindir}/sudoedit"
> >  FILES:${PN}-lib = "${localstatedir} ${libexecdir} ${sysconfdir} ${libdir}
> > ${nonarch_libdir}"
> > +
> > +CVE_STATUS[CVE-2025-64170] = "cpe-incorrect: this CVE is for sudo-rs"
> > +CVE_STATUS[CVE-2025-64517] = "cpe-incorrect: this CVE is for sudo-rs"
> 


-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

RE: [PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517

[Marko, Peter]

> -----Original Message-----
> From: Benjamin Robin <benjamin.robin@bootlin.com>
> Sent: Monday, April 27, 2026 9:13 AM
> To: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517
> 
> On Sunday, April 26, 2026 at 9:17 PM, Marko, Peter wrote:
> >
> > > -----Original Message-----
> > > From: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> > > Sent: Sunday, April 26, 2026 8:50 PM
> > > To: openembedded-core@lists.openembedded.org
> > > Cc: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> > > Subject: [PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517
> > >
> > > From: Peter Marko <peter.marko@siemens.com>
> > >
> > > These CVEs are for sudo-rs, not sudo.
> > > It can be easily deducted from first word in NVD descripotion.
> > > Also cvelistV5 product is "sudo-re".
> > >
> > > It looks line that new version of sbom-cve-check matches product with
> > > startsWith instead of equals?
> >
> > Benjamin, any idea about this topic?
> 
> Yes, sadly the CPE of sudo-rs is trifectatech:sudo.
> Why this is the official CPE of sudo-rs, I don't know...
> 
> What it is happening:
>  - From https://cveawg.mitre.org/api/cve/CVE-2025-64170
>    we extract vendor and product name, then we look the products database
>    which is built in sbom-cve-check.
>  - The returned CPE are "memorysafety:sudo", "trifectatech:sudo"
>  - Then we check if the CPE in the SBOM matches with these CPE.
>    Currently sudo is declared as: *:sudo, which matches trifectatech:sudo.

Hello Benjamin,

I will sent CVE_PRODUCT update to get rid of some older sudo-rs CVE.

However for these two CVEs, I can still only see "sudo-rs" as product, not "sudo", also via link you have provided from cveawg.org/api.

Peter

> 
> The easy fix is to declare the proper CPE of sudo using CVE_PRODUCT,
> which should be set to "sudo_project:sudo".
> 
> This behavior is documented here:
> https://sbom-cve-check.readthedocs.io/en/latest/design.html#find-applicable-cve
> 
> >
> > >
> > > Signed-off-by: Peter Marko <peter.marko@siemens.com>
> > > ---
> > >  meta/recipes-extended/sudo/sudo_1.9.17p2.bb | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/meta/recipes-extended/sudo/sudo_1.9.17p2.bb b/meta/recipes-
> > > extended/sudo/sudo_1.9.17p2.bb
> > > index d6ee881f8c..12f81c5d4a 100644
> > > --- a/meta/recipes-extended/sudo/sudo_1.9.17p2.bb
> > > +++ b/meta/recipes-extended/sudo/sudo_1.9.17p2.bb
> > > @@ -60,3 +60,6 @@ RDEPENDS:${PN} += "${SUDO_PACKAGES}"
> > >
> > >  FILES:${PN}-sudo = "${bindir}/sudo ${bindir}/sudoedit"
> > >  FILES:${PN}-lib = "${localstatedir} ${libexecdir} ${sysconfdir} ${libdir}
> > > ${nonarch_libdir}"
> > > +
> > > +CVE_STATUS[CVE-2025-64170] = "cpe-incorrect: this CVE is for sudo-rs"
> > > +CVE_STATUS[CVE-2025-64517] = "cpe-incorrect: this CVE is for sudo-rs"
> >
> 
> 
> --
> Benjamin Robin, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 
> 

Re: [PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517

[Benjamin Robin]

Hello Peter,

On Tuesday, April 28, 2026 at 6:51 PM, Marko, Peter wrote:
> 
> > > Benjamin, any idea about this topic?
> > 
> > Yes, sadly the CPE of sudo-rs is trifectatech:sudo.
> > Why this is the official CPE of sudo-rs, I don't know...
> > 
> > What it is happening:
> >  - From https://cveawg.mitre.org/api/cve/CVE-2025-64170
> >    we extract vendor and product name, then we look the products database
> >    which is built in sbom-cve-check.
> >  - The returned CPE are "memorysafety:sudo", "trifectatech:sudo"
> >  - Then we check if the CPE in the SBOM matches with these CPE.
> >    Currently sudo is declared as: *:sudo, which matches trifectatech:sudo.
> 
> Hello Benjamin,
> 
> I will sent CVE_PRODUCT update to get rid of some older sudo-rs CVE.
> 
> However for these two CVEs, I can still only see "sudo-rs" as product, not "sudo", also via link you have provided from cveawg.org/api.

Yes, but this is not a CPE. As explained previously (see the steps detailed
above in the previous email), using the vendor/product names extracted from
the associated field, we look in the products database for an associated CPE:
https://github.com/bootlin/sbom-cve-check/blob/v1.3.0/src/sbom_cve_check/products/products.toml#L1688

The associated CPE is "trifectatech:sudo" (which is used by the NVD database).
Why the NVD database provided this CPE, I don't know... But this is the
"official" CPE for sudo-rs as I am aware.

> Peter
> 
> > 
> > The easy fix is to declare the proper CPE of sudo using CVE_PRODUCT,
> > which should be set to "sudo_project:sudo".
> > 
> > This behavior is documented here:
> > https://sbom-cve-check.readthedocs.io/en/latest/design.html#find-applicable-cve


-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

RE: [PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517

[Marko, Peter]

> -----Original Message-----
> From: Benjamin Robin <benjamin.robin@bootlin.com>
> Sent: Wednesday, April 29, 2026 9:24 AM
> To: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517
> 
> Hello Peter,
> 
> On Tuesday, April 28, 2026 at 6:51 PM, Marko, Peter wrote:
> >
> > > > Benjamin, any idea about this topic?
> > >
> > > Yes, sadly the CPE of sudo-rs is trifectatech:sudo.
> > > Why this is the official CPE of sudo-rs, I don't know...
> > >
> > > What it is happening:
> > >  - From https://cveawg.mitre.org/api/cve/CVE-2025-64170
> > >    we extract vendor and product name, then we look the products database
> > >    which is built in sbom-cve-check.
> > >  - The returned CPE are "memorysafety:sudo", "trifectatech:sudo"
> > >  - Then we check if the CPE in the SBOM matches with these CPE.
> > >    Currently sudo is declared as: *:sudo, which matches trifectatech:sudo.
> >
> > Hello Benjamin,
> >
> > I will sent CVE_PRODUCT update to get rid of some older sudo-rs CVE.
> >
> > However for these two CVEs, I can still only see "sudo-rs" as product, not "sudo",
> also via link you have provided from cveawg.org/api.
> 
> Yes, but this is not a CPE. As explained previously (see the steps detailed
> above in the previous email), using the vendor/product names extracted from
> the associated field, we look in the products database for an associated CPE:
> https://github.com/bootlin/sbom-cve-
> check/blob/v1.3.0/src/sbom_cve_check/products/products.toml#L1688

Thanks for the explanation.
Finally, I'm starting to understand how some CVEs get assigned to components where I'd not expect them.

How was that toml file created? Manual work?
For sudo I think the table is correct (although I don't understand NVD motivation for that).

However for SDL (CVE-2026-35444) it looks wrong:
https://github.com/bootlin/sbom-cve-check/blob/v1.3.0/src/sbom_cve_check/products/products.toml#L1608
Why does it map sdl and sdl_image and simple_directmedia_layer together?
There are distinctive CPEs for both sdl and sdl_image in NVD DB...

Peter



> 
> The associated CPE is "trifectatech:sudo" (which is used by the NVD database).
> Why the NVD database provided this CPE, I don't know... But this is the
> "official" CPE for sudo-rs as I am aware.
> 
> > Peter
> >
> > >
> > > The easy fix is to declare the proper CPE of sudo using CVE_PRODUCT,
> > > which should be set to "sudo_project:sudo".
> > >
> > > This behavior is documented here:
> > > https://sbom-cve-check.readthedocs.io/en/latest/design.html#find-applicable-cve
> 
> 
> --
> Benjamin Robin, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 
> 

Re: [PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517

[Benjamin Robin]

Hello Peter,

On Wednesday, April 29, 2026 at 7:13 PM, Marko, Peter wrote:

> > > Hello Benjamin,
> > >
> > > I will sent CVE_PRODUCT update to get rid of some older sudo-rs CVE.
> > >
> > > However for these two CVEs, I can still only see "sudo-rs" as product, not "sudo",
> > also via link you have provided from cveawg.org/api.
> > 
> > Yes, but this is not a CPE. As explained previously (see the steps detailed
> > above in the previous email), using the vendor/product names extracted from
> > the associated field, we look in the products database for an associated CPE:
> > https://github.com/bootlin/sbom-cve-
> > check/blob/v1.3.0/src/sbom_cve_check/products/products.toml#L1688
> 
> Thanks for the explanation.
> Finally, I'm starting to understand how some CVEs get assigned to components where I'd not expect them.
> 
> How was that toml file created? Manual work?
> For sudo I think the table is correct (although I don't understand NVD motivation for that).

This is a mix of an automated script and of a manual work...
 
> However for SDL (CVE-2026-35444) it looks wrong:
> https://github.com/bootlin/sbom-cve-check/blob/v1.3.0/src/sbom_cve_check/products/products.toml#L1608
> Why does it map sdl and sdl_image and simple_directmedia_layer together?
> There are distinctive CPEs for both sdl and sdl_image in NVD DB...

From my understanding this was the same component, but it is clearly
not the case...

- https://nvd.nist.gov/vuln/detail/CVE-2019-7573 use this CPE
  "cpe:2.3:a:libsdl:simple_directmedia_layer:*:*:*:*:*:*:*:*"
  and refer to both SDL 1 and 2. The referenced code looks like it is:
  https://github.com/libsdl-org/SDL/blob/main/src/audio/SDL_wave.c#L376

- https://nvd.nist.gov/vuln/detail/CVE-2008-0544 use this CPE
  "cpe:2.3:a:sdl:sdl_image:1.2.6:*:*:*:*:*:*:*"
   and refer to SDL_image 1. The referenced code looks like it is:
   https://github.com/libsdl-org/SDL_image/blob/SDL-1.2/IMG_lbm.c

> Peter

I expected to make several mistakes. This is a first version, and it is
going to be improved and fixed in the long run (at least this was my plan).

-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 1/6] sudo: set status of CVE-2025-64170 and CVE-2025-64517

[Benjamin Robin]

On Thursday, April 30, 2026 at 9:21 AM, Benjamin Robin wrote:
> Hello Peter,
> 
> On Wednesday, April 29, 2026 at 7:13 PM, Marko, Peter wrote:
> 
> > > > Hello Benjamin,
> > > >
> > > > I will sent CVE_PRODUCT update to get rid of some older sudo-rs CVE.
> > > >
> > > > However for these two CVEs, I can still only see "sudo-rs" as product, not "sudo",
> > > also via link you have provided from cveawg.org/api.
> > > 
> > > Yes, but this is not a CPE. As explained previously (see the steps detailed
> > > above in the previous email), using the vendor/product names extracted from
> > > the associated field, we look in the products database for an associated CPE:
> > > https://github.com/bootlin/sbom-cve-
> > > check/blob/v1.3.0/src/sbom_cve_check/products/products.toml#L1688
> > 
> > Thanks for the explanation.
> > Finally, I'm starting to understand how some CVEs get assigned to components where I'd not expect them.
> > 
> > How was that toml file created? Manual work?
> > For sudo I think the table is correct (although I don't understand NVD motivation for that).
> 
> This is a mix of an automated script and of a manual work...
>  
> > However for SDL (CVE-2026-35444) it looks wrong:
> > https://github.com/bootlin/sbom-cve-check/blob/v1.3.0/src/sbom_cve_check/products/products.toml#L1608
> > Why does it map sdl and sdl_image and simple_directmedia_layer together?
> > There are distinctive CPEs for both sdl and sdl_image in NVD DB...
> 
> From my understanding this was the same component, but it is clearly
> not the case...
> 
> - https://nvd.nist.gov/vuln/detail/CVE-2019-7573 use this CPE
>   "cpe:2.3:a:libsdl:simple_directmedia_layer:*:*:*:*:*:*:*:*"
>   and refer to both SDL 1 and 2. The referenced code looks like it is:
>   https://github.com/libsdl-org/SDL/blob/main/src/audio/SDL_wave.c#L376
> 
> - https://nvd.nist.gov/vuln/detail/CVE-2008-0544 use this CPE
>   "cpe:2.3:a:sdl:sdl_image:1.2.6:*:*:*:*:*:*:*"
>    and refer to SDL_image 1. The referenced code looks like it is:
>    https://github.com/libsdl-org/SDL_image/blob/SDL-1.2/IMG_lbm.c

After checking (again), I now understand my mistake.

In the CVE list, "Simple DirectMedia Layer" product name always refers to
the SDL_image component.

I am going to remove this entry from the product database, as it only
covers fewer than 10 (old) CVEs.
 
> > Peter
> 
> I expected to make several mistakes. This is a first version, and it is
> going to be improved and fixed in the long run (at least this was my plan).
> 
> 


-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com