[OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives

[OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives

[Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco)]

From: Het Patel <hetpat@cisco.com>

- Added the vendor to CVE_PRODUCT to prevent false positives.

Signed-off-by: Het Patel <hetpat@cisco.com>
---
 meta/recipes-core/util-linux/util-linux.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc
index deb9bfd064..81fefa5afa 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -24,4 +24,4 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/util-linux/v${MAJOR_VERSION}/util-lin
 
 SRC_URI[sha256sum] = "3330d873f0fceb5560b89a7dc14e4f3288bbd880e96903ed9b50ec2b5799e58b"
 
-CVE_PRODUCT = "util-linux"
+CVE_PRODUCT = "kernel:util-linux"

[OE-core] [PATCH v1] mpfr: Add vendor to CVE_PRODUCT to exclude false positives

[Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco)]

From: Het Patel <hetpat@cisco.com>

- Added the vendor to CVE_PRODUCT to prevent false positives.

Signed-off-by: Het Patel <hetpat@cisco.com>
---
 meta/recipes-support/mpfr/mpfr_4.2.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/mpfr/mpfr_4.2.2.bb b/meta/recipes-support/mpfr/mpfr_4.2.2.bb
index 4d1747c3fd..81f3a0297b 100644
--- a/meta/recipes-support/mpfr/mpfr_4.2.2.bb
+++ b/meta/recipes-support/mpfr/mpfr_4.2.2.bb
@@ -9,7 +9,7 @@ inherit autotools texinfo
 LIC_FILES_CHKSUM = "file://COPYING;md5=1ebbd3e34237af26da5dc08a4e440464 \
                     file://COPYING.LESSER;md5=3000208d539ec061b899bce1d9ce9404 \
                     "
-CVE_PRODUCT = "gnu_mpfr"
+CVE_PRODUCT = "mpfr:gnu_mpfr"
 
 DEPENDS = "gmp"
 

Re: [OE-core] [PATCH v1] mpfr: Add vendor to CVE_PRODUCT to exclude false positives

[Ross Burton]

On 26 Feb 2026, at 12:54, Het Patel via lists.openembedded.org <hetpat=cisco.com@lists.openembedded.org> wrote:
> 
> From: Het Patel <hetpat@cisco.com>
> 
> - Added the vendor to CVE_PRODUCT to prevent false positives.

What false positives?  If this is actually “add the vendor because existing CVEs use this exact CPE” then say so, but please reassure us without having to do our own verification that this doesn’t actually mean we miss some CVEs.

Basically, changing the CVE_PRODUCT is good if it improves the detection, but changes should be backed up with evidence.

Ross

[OE-core] [PATCH v1] python3-dbus: Add CVE_PRODUCT to support product name

[Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco)]

From: Het Patel <hetpat@cisco.com>

- Set CVE_PRODUCT to align with the NVD CPE and ensure correct CVE
reporting.

Signed-off-by: Het Patel <hetpat@cisco.com>
---
 meta/recipes-devtools/python/python3-dbus_1.4.0.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/python/python3-dbus_1.4.0.bb b/meta/recipes-devtools/python/python3-dbus_1.4.0.bb
index 2854eda30a..00b75653fe 100644
--- a/meta/recipes-devtools/python/python3-dbus_1.4.0.bb
+++ b/meta/recipes-devtools/python/python3-dbus_1.4.0.bb
@@ -21,3 +21,6 @@ RDEPENDS:${PN} = "python3-io python3-logging python3-stringold python3-threading
 FILES:${PN}-dev += "${libdir}/pkgconfig"
 
 BBCLASSEXTEND = "native nativesdk"
+
+# Add CVE_PRODUCT to match the NVD CPE product name
+CVE_PRODUCT = "freedesktop:dbus"

Re: [OE-core] [PATCH v1] python3-dbus: Add CVE_PRODUCT to support product name

[Ross Burton]

On 26 Feb 2026, at 12:54, Het Patel via lists.openembedded.org <hetpat=cisco.com@lists.openembedded.org> wrote:
> 
> From: Het Patel <hetpat@cisco.com>
> 
> - Set CVE_PRODUCT to align with the NVD CPE and ensure correct CVE
> reporting.

Have there been any CVEs for python-dbus so that you’re sure that you’re using the right CPE?  This is the CPE for the fdo daemon and libdbus and python-dbus is a separate project, so you can’t know in advance what the CPE will be unless it’s been stated in advance, or there are CVEs to reference.

Cheers,
Ross

Re: [OE-core] [PATCH v1] python3-dbus: Add CVE_PRODUCT to support product name

[Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco)]

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

This assessment appears to be correct, Ross. `freedesktop:dbus` in NVD CPE refers specifically to the core D-Bus daemon and libdbus, not to `python3-dbus`, which is a separate Python binding layer with its own source tree, versioning, and maintainership. Since no confirmed CVEs are directly attributed to `python3-dbus` in current NVD data, there is no valid basis for this CPE mapping.

A dependency relationship alone does not transfer CVE applicability. Setting `CVE_PRODUCT = "freedesktop:dbus"` in `python3-dbus` risks over-attributing `dbus` vulnerabilities onto `python3-dbus`, creating false positives in CVE scanning and a misleading impression that a `dbus` patch resolves `python3-dbus` issues. `python3-dbus` must be treated as a separate product identity for accurate CVE attribution.

Requesting the community team to drop this patch:
https://git.openembedded.org/openembedded-core/commit/?h=master-next&id=4d04761a4a69
________________________________
From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> on behalf of Ross Burton via lists.openembedded.org <ross.burton=arm.com@lists.openembedded.org>
Sent: Tuesday, March 3, 2026 8:49 PM
To: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) <hetpat@cisco.com>
Cc: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH v1] python3-dbus: Add CVE_PRODUCT to support product name

On 26 Feb 2026, at 12:54, Het Patel via lists.openembedded.org <hetpat=cisco.com@lists.openembedded.org> wrote:
>
> From: Het Patel <hetpat@cisco.com>
>
> - Set CVE_PRODUCT to align with the NVD CPE and ensure correct CVE
> reporting.

Have there been any CVEs for python-dbus so that you’re sure that you’re using the right CPE?  This is the CPE for the fdo daemon and libdbus and python-dbus is a separate project, so you can’t know in advance what the CPE will be unless it’s been stated in advance, or there are CVEs to reference.

Cheers,
Ross

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

RE: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives

[Marko, Peter]

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Het Patel via
> lists.openembedded.org
> Sent: Thursday, February 26, 2026 13:54
> To: openembedded-core@lists.openembedded.org
> Cc: xe-linux-external@cisco.com; vchavda@cisco.com
> Subject: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to
> exclude false positives
> 
> From: Het Patel <hetpat@cisco.com>
> 
> - Added the vendor to CVE_PRODUCT to prevent false positives.
> 
> Signed-off-by: Het Patel <hetpat@cisco.com>
> ---
>  meta/recipes-core/util-linux/util-linux.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-
> linux/util-linux.inc
> index deb9bfd064..81fefa5afa 100644
> --- a/meta/recipes-core/util-linux/util-linux.inc
> +++ b/meta/recipes-core/util-linux/util-linux.inc
> @@ -24,4 +24,4 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/util-
> linux/v${MAJOR_VERSION}/util-lin
> 
>  SRC_URI[sha256sum] =
> "3330d873f0fceb5560b89a7dc14e4f3288bbd880e96903ed9b50ec2b5799e58b"
> 
> -CVE_PRODUCT = "util-linux"
> +CVE_PRODUCT = "kernel:util-linux"

Which false positives are you trying to remove?
I think that all of these are correct and there are not false positives:

sqlite> select count(*), vendor, product from products where product like '%util-linux%' group by vendor, product;
29|andries_brouwer|util-linux
16|kernel|util-linux
56|linux|util-linux
1|util-linux_project|util-linux

Re: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives

[Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco)]

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

Hi,

A review was conducted of the database entries, upstream sources, and the associated CVE records for util-linux. Below is a detailed analysis and the corresponding rationale.

Observations:

  *
There are four vendor names associated with the util‑linux product: andries_brouwer, linux, util-linux_project, and kernel.
  *
`andries_brouwer:util-linux` and `linux:util-linux` are legacy entries from older CVEs (pre-2012).
  *
`util-linux_project` represents a transitional vendor namespace, now largely deprecated.

Upstream Source Mapping:

  *
The current upstream source code repositories found from README are:
     *
GitHub: https://github.com/util-linux/util-linux.git
     *
Kernel.org: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
  *
CVEs from 2018–2024 referencing util-linux use the CPE vendor `kernel`:

        "cpe:2.3:a:kernel:util-linux"

  *
Legacy CVEs (e.g., CVE-2008-1926, CVE-2011-1675/1676/1677) sometimes reference `linux:util-linux` or `andries_brouwer:util-linux`, but these are historical and correspond to older releases no longer maintained.

Conclusion:

  *
All entries are “correct” in the sense that they exist in historical CVE/CPE mappings.
  *
However, only `kernel:util-linux` corresponds to the current upstream project and is used in **active CVE tracking** today.

False Positive Analysis:

  1.
The proposed change aligns CVE mapping with the official upstream project.
  2.
It ensures that CVEs from modern releases are correctly linked to the live repository.
  3.
It maintains historical records in the database for reference, but prevents them from being misattributed to “current” upstream versions.

Key point:

  *
There are no false positives being removed and historical entries (`linux:util-linux`, `andries_brouwer:util-linux`) remain in the database for archival purposes.

Commit message will be updated accordingly.

Regards.
Het
________________________________
From: Marko, Peter <Peter.Marko@siemens.com>
Sent: Thursday, February 26, 2026 6:47 PM
To: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) <hetpat@cisco.com>; openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>
Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com>; Viral Chavda (vchavda) <vchavda@cisco.com>
Subject: RE: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives



> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Het Patel via
> lists.openembedded.org
> Sent: Thursday, February 26, 2026 13:54
> To: openembedded-core@lists.openembedded.org
> Cc: xe-linux-external@cisco.com; vchavda@cisco.com
> Subject: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to
> exclude false positives
>
> From: Het Patel <hetpat@cisco.com>
>
> - Added the vendor to CVE_PRODUCT to prevent false positives.
>
> Signed-off-by: Het Patel <hetpat@cisco.com>
> ---
>  meta/recipes-core/util-linux/util-linux.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-
> linux/util-linux.inc
> index deb9bfd064..81fefa5afa 100644
> --- a/meta/recipes-core/util-linux/util-linux.inc
> +++ b/meta/recipes-core/util-linux/util-linux.inc
> @@ -24,4 +24,4 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/util-
> linux/v${MAJOR_VERSION}/util-lin
>
>  SRC_URI[sha256sum] =
> "3330d873f0fceb5560b89a7dc14e4f3288bbd880e96903ed9b50ec2b5799e58b"
>
> -CVE_PRODUCT = "util-linux"
> +CVE_PRODUCT = "kernel:util-linux"

Which false positives are you trying to remove?
I think that all of these are correct and there are not false positives:

sqlite> select count(*), vendor, product from products where product like '%util-linux%' group by vendor, product;
29|andries_brouwer|util-linux
16|kernel|util-linux
56|linux|util-linux
1|util-linux_project|util-linux


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

RE: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives

[Marko, Peter]

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

Hello,

It is important that all historical entries are kept known to Yocto build system.
Otherwise spdx/vex will not indicate the historical CVEs as resolved.

Therefore this change is incorrect.
Alternatively you could limit it to the 4 historical vendor strings, but not limiting it to only the current vendor string.

Peter

From: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) <hetpat@cisco.com>
Sent: Friday, February 27, 2026 10:05
To: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>; openembedded-core@lists.openembedded.org
Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com>; Viral Chavda (vchavda) <vchavda@cisco.com>
Subject: Re: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives

Hi,

A review was conducted of the database entries, upstream sources, and the associated CVE records for util-linux. Below is a detailed analysis and the corresponding rationale.

Observations:

  *   There are four vendor names associated with the util‑linux product: andries_brouwer, linux, util-linux_project, and kernel.

  *   `andries_brouwer:util-linux` and `linux:util-linux` are legacy entries from older CVEs (pre-2012).

  *   `util-linux_project` represents a transitional vendor namespace, now largely deprecated.

Upstream Source Mapping:

  *   The current upstream source code repositories found from README are:

     *   GitHub: https://github.com/util-linux/util-linux.git

     *   Kernel.org: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git

  *   CVEs from 2018–2024 referencing util-linux use the CPE vendor `kernel`:
        "cpe:2.3:a:kernel:util-linux"

  *   Legacy CVEs (e.g., CVE-2008-1926, CVE-2011-1675/1676/1677) sometimes reference `linux:util-linux` or `andries_brouwer:util-linux`, but these are historical and correspond to older releases no longer maintained.

Conclusion:

  *   All entries are “correct” in the sense that they exist in historical CVE/CPE mappings.

  *   However, only `kernel:util-linux` corresponds to the current upstream project and is used in **active CVE tracking** today.

False Positive Analysis:

  1.  The proposed change aligns CVE mapping with the official upstream project.

  1.  It ensures that CVEs from modern releases are correctly linked to the live repository.

  1.  It maintains historical records in the database for reference, but prevents them from being misattributed to “current” upstream versions.

Key point:

  *   There are no false positives being removed and historical entries (`linux:util-linux`, `andries_brouwer:util-linux`) remain in the database for archival purposes.

Commit message will be updated accordingly.

Regards.
Het
________________________________
From: Marko, Peter <Peter.Marko@siemens.com<mailto:Peter.Marko@siemens.com>>
Sent: Thursday, February 26, 2026 6:47 PM
To: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) <hetpat@cisco.com<mailto:hetpat@cisco.com>>; openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org> <openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>>
Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com<mailto:xe-linux-external@cisco.com>>; Viral Chavda (vchavda) <vchavda@cisco.com<mailto:vchavda@cisco.com>>
Subject: RE: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives



> -----Original Message-----
> From: openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org> <openembedded-
> core@lists.openembedded.org<mailto:core@lists.openembedded.org>> On Behalf Of Het Patel via
> lists.openembedded.org
> Sent: Thursday, February 26, 2026 13:54
> To: openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>
> Cc: xe-linux-external@cisco.com<mailto:xe-linux-external@cisco.com>; vchavda@cisco.com<mailto:vchavda@cisco.com>
> Subject: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to
> exclude false positives
>
> From: Het Patel <hetpat@cisco.com<mailto:hetpat@cisco.com>>
>
> - Added the vendor to CVE_PRODUCT to prevent false positives.
>
> Signed-off-by: Het Patel <hetpat@cisco.com<mailto:hetpat@cisco.com>>
> ---
>  meta/recipes-core/util-linux/util-linux.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-
> linux/util-linux.inc
> index deb9bfd064..81fefa5afa 100644
> --- a/meta/recipes-core/util-linux/util-linux.inc
> +++ b/meta/recipes-core/util-linux/util-linux.inc
> @@ -24,4 +24,4 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/util-
> linux/v${MAJOR_VERSION}/util-lin
>
>  SRC_URI[sha256sum] =
> "3330d873f0fceb5560b89a7dc14e4f3288bbd880e96903ed9b50ec2b5799e58b"
>
> -CVE_PRODUCT = "util-linux"
> +CVE_PRODUCT = "kernel:util-linux"

Which false positives are you trying to remove?
I think that all of these are correct and there are not false positives:

sqlite> select count(*), vendor, product from products where product like '%util-linux%' group by vendor, product;
29|andries_brouwer|util-linux
16|kernel|util-linux
56|linux|util-linux
1|util-linux_project|util-linux

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

Re: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives

[Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco)]

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

Hello Peter,

I agree that historical CVEs must remain resolvable in SPDX/VEX. However, the issue we are trying to address is different. The core concern is the scope and signal-to-noise ratio. If we include all historical NVD CPE vendor namespaces for util-linux in active reporting - including legacy aliases such as `util-linux_project` - we effectively introduce deprecated namespaces and CVEs that apply only to very old source trees. In practice, this can result in hundreds of CPE/version combinations, many tied to code that has been removed or heavily refactored, which significantly increases developer triage effort.

From a reporting perspective, this adds noise, increases review overhead, and raises the maintenance burden within CI and security pipelines. There is an important distinction between archival completeness(essentially replicating the full NVD dataset) and operational relevance(what actually applies to the current codebase used in Yocto builds). Publishing the entire NVD surface area for util-linux risks turning our report into a mirror of NVD rather than a focused and actionable vulnerability assessment.

We are mindful of the versions actually in use. Many CVEs under `andries_brouwer` or the legacy `linux` vendor namespace relate to releases from 2005–2011, while the Yocto build integrates specific, maintained versions of util-linux. Automatically including all historical vendor namespaces can lead to unnecessary VEX justifications and additional developer workload without materially improving the security posture. Because NVD contains deprecated CPEs, aliases, and historical vendor transitions, treating them all equally in operational reporting can inflate results, require review of irrelevant legacy CVEs, and ultimately reduce signal quality.

Please feel free to share your perspective.

Thanks & Regards,
Het.
________________________________
From: Marko, Peter <Peter.Marko@siemens.com>
Sent: Friday, February 27, 2026 2:40 PM
To: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) <hetpat@cisco.com>; openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>
Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com>; Viral Chavda (vchavda) <vchavda@cisco.com>
Subject: RE: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives


Hello,



It is important that all historical entries are kept known to Yocto build system.

Otherwise spdx/vex will not indicate the historical CVEs as resolved.



Therefore this change is incorrect.

Alternatively you could limit it to the 4 historical vendor strings, but not limiting it to only the current vendor string.



Peter



From: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) <hetpat@cisco.com>
Sent: Friday, February 27, 2026 10:05
To: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>; openembedded-core@lists.openembedded.org
Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com>; Viral Chavda (vchavda) <vchavda@cisco.com>
Subject: Re: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives



Hi,



A review was conducted of the database entries, upstream sources, and the associated CVE records for util-linux. Below is a detailed analysis and the corresponding rationale.



Observations:

  *   There are four vendor names associated with the util‑linux product: andries_brouwer, linux, util-linux_project, and kernel.

  *   `andries_brouwer:util-linux` and `linux:util-linux` are legacy entries from older CVEs (pre-2012).

  *   `util-linux_project` represents a transitional vendor namespace, now largely deprecated.



Upstream Source Mapping:

  *   The current upstream source code repositories found from README are:

     *   GitHub: https://github.com/util-linux/util-linux.git

     *   Kernel.org: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git

  *   CVEs from 2018–2024 referencing util-linux use the CPE vendor `kernel`:

        "cpe:2.3:a:kernel:util-linux"

  *   Legacy CVEs (e.g., CVE-2008-1926, CVE-2011-1675/1676/1677) sometimes reference `linux:util-linux` or `andries_brouwer:util-linux`, but these are historical and correspond to older releases no longer maintained.



Conclusion:

  *   All entries are “correct” in the sense that they exist in historical CVE/CPE mappings.

  *   However, only `kernel:util-linux` corresponds to the current upstream project and is used in **active CVE tracking** today.



False Positive Analysis:

  1.  The proposed change aligns CVE mapping with the official upstream project.

  1.  It ensures that CVEs from modern releases are correctly linked to the live repository.

  1.  It maintains historical records in the database for reference, but prevents them from being misattributed to “current” upstream versions.



Key point:

  *   There are no false positives being removed and historical entries (`linux:util-linux`, `andries_brouwer:util-linux`) remain in the database for archival purposes.



Commit message will be updated accordingly.



Regards.

Het

________________________________

From: Marko, Peter <Peter.Marko@siemens.com<mailto:Peter.Marko@siemens.com>>
Sent: Thursday, February 26, 2026 6:47 PM
To: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) <hetpat@cisco.com<mailto:hetpat@cisco.com>>; openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org> <openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>>
Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com<mailto:xe-linux-external@cisco.com>>; Viral Chavda (vchavda) <vchavda@cisco.com<mailto:vchavda@cisco.com>>
Subject: RE: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives




> -----Original Message-----
> From: openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org> <openembedded-
> core@lists.openembedded.org<mailto:core@lists.openembedded.org>> On Behalf Of Het Patel via
> lists.openembedded.org
> Sent: Thursday, February 26, 2026 13:54
> To: openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>
> Cc: xe-linux-external@cisco.com<mailto:xe-linux-external@cisco.com>; vchavda@cisco.com<mailto:vchavda@cisco.com>
> Subject: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to
> exclude false positives
>
> From: Het Patel <hetpat@cisco.com<mailto:hetpat@cisco.com>>
>
> - Added the vendor to CVE_PRODUCT to prevent false positives.
>
> Signed-off-by: Het Patel <hetpat@cisco.com<mailto:hetpat@cisco.com>>
> ---
>  meta/recipes-core/util-linux/util-linux.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-
> linux/util-linux.inc
> index deb9bfd064..81fefa5afa 100644
> --- a/meta/recipes-core/util-linux/util-linux.inc
> +++ b/meta/recipes-core/util-linux/util-linux.inc
> @@ -24,4 +24,4 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/util-
> linux/v${MAJOR_VERSION}/util-lin
>
>  SRC_URI[sha256sum] =
> "3330d873f0fceb5560b89a7dc14e4f3288bbd880e96903ed9b50ec2b5799e58b"
>
> -CVE_PRODUCT = "util-linux"
> +CVE_PRODUCT = "kernel:util-linux"

Which false positives are you trying to remove?
I think that all of these are correct and there are not false positives:

sqlite> select count(*), vendor, product from products where product like '%util-linux%' group by vendor, product;
29|andries_brouwer|util-linux
16|kernel|util-linux
56|linux|util-linux
1|util-linux_project|util-linux

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

RE: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives

[Marko, Peter]

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

Hello Het,

Thanks for explaining your use-case.
However this change in current form is wrong because it removes existing (although a bit old) CVEs from Yocto reports.
And reporting all existing CVEs for a component is currently an integral part of the reports.
From my perspective, your change looks like “just report CVEs from 2012 onwards” which I think we also don’t want to take.

If you would like to change the current behavior of “replicating NVD DB”, that should be discussed and implemented globally, not in a single recipe.
I could image some variable which would (if configured) take only single vendor:product namespace or map all namespaces into this “current” one.

(adding Joshua and Marta to the discussion for spdx/vex discussions)

Best Regards,
  Peter

From: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) <hetpat@cisco.com>
Sent: Friday, February 27, 2026 13:52
To: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>; openembedded-core@lists.openembedded.org
Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com>; Viral Chavda (vchavda) <vchavda@cisco.com>
Subject: Re: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives

Hello Peter,

I agree that historical CVEs must remain resolvable in SPDX/VEX. However, the issue we are trying to address is different. The core concern is the scope and signal-to-noise ratio. If we include all historical NVD CPE vendor namespaces for util-linux in active reporting - including legacy aliases such as `util-linux_project` - we effectively introduce deprecated namespaces and CVEs that apply only to very old source trees. In practice, this can result in hundreds of CPE/version combinations, many tied to code that has been removed or heavily refactored, which significantly increases developer triage effort.

From a reporting perspective, this adds noise, increases review overhead, and raises the maintenance burden within CI and security pipelines. There is an important distinction between archival completeness(essentially replicating the full NVD dataset) and operational relevance(what actually applies to the current codebase used in Yocto builds). Publishing the entire NVD surface area for util-linux risks turning our report into a mirror of NVD rather than a focused and actionable vulnerability assessment.

We are mindful of the versions actually in use. Many CVEs under `andries_brouwer` or the legacy `linux` vendor namespace relate to releases from 2005–2011, while the Yocto build integrates specific, maintained versions of util-linux. Automatically including all historical vendor namespaces can lead to unnecessary VEX justifications and additional developer workload without materially improving the security posture. Because NVD contains deprecated CPEs, aliases, and historical vendor transitions, treating them all equally in operational reporting can inflate results, require review of irrelevant legacy CVEs, and ultimately reduce signal quality.

Please feel free to share your perspective.

Thanks & Regards,
Het.
________________________________
From: Marko, Peter <Peter.Marko@siemens.com<mailto:Peter.Marko@siemens.com>>
Sent: Friday, February 27, 2026 2:40 PM
To: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) <hetpat@cisco.com<mailto:hetpat@cisco.com>>; openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org> <openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>>
Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com<mailto:xe-linux-external@cisco.com>>; Viral Chavda (vchavda) <vchavda@cisco.com<mailto:vchavda@cisco.com>>
Subject: RE: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives


Hello,



It is important that all historical entries are kept known to Yocto build system.

Otherwise spdx/vex will not indicate the historical CVEs as resolved.



Therefore this change is incorrect.

Alternatively you could limit it to the 4 historical vendor strings, but not limiting it to only the current vendor string.



Peter



From: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) <hetpat@cisco.com<mailto:hetpat@cisco.com>>
Sent: Friday, February 27, 2026 10:05
To: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com<mailto:Peter.Marko@siemens.com>>; openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>
Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com<mailto:xe-linux-external@cisco.com>>; Viral Chavda (vchavda) <vchavda@cisco.com<mailto:vchavda@cisco.com>>
Subject: Re: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives



Hi,



A review was conducted of the database entries, upstream sources, and the associated CVE records for util-linux. Below is a detailed analysis and the corresponding rationale.



Observations:

  *   There are four vendor names associated with the util‑linux product: andries_brouwer, linux, util-linux_project, and kernel.

  *   `andries_brouwer:util-linux` and `linux:util-linux` are legacy entries from older CVEs (pre-2012).

  *   `util-linux_project` represents a transitional vendor namespace, now largely deprecated.



Upstream Source Mapping:

  *   The current upstream source code repositories found from README are:

     *   GitHub: https://github.com/util-linux/util-linux.git

     *   Kernel.org: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git

  *   CVEs from 2018–2024 referencing util-linux use the CPE vendor `kernel`:

        "cpe:2.3:a:kernel:util-linux"

  *   Legacy CVEs (e.g., CVE-2008-1926, CVE-2011-1675/1676/1677) sometimes reference `linux:util-linux` or `andries_brouwer:util-linux`, but these are historical and correspond to older releases no longer maintained.



Conclusion:

  *   All entries are “correct” in the sense that they exist in historical CVE/CPE mappings.

  *   However, only `kernel:util-linux` corresponds to the current upstream project and is used in **active CVE tracking** today.



False Positive Analysis:

  1.  The proposed change aligns CVE mapping with the official upstream project.

  1.  It ensures that CVEs from modern releases are correctly linked to the live repository.

  1.  It maintains historical records in the database for reference, but prevents them from being misattributed to “current” upstream versions.



Key point:

  *   There are no false positives being removed and historical entries (`linux:util-linux`, `andries_brouwer:util-linux`) remain in the database for archival purposes.



Commit message will be updated accordingly.



Regards.

Het

________________________________

From: Marko, Peter <Peter.Marko@siemens.com<mailto:Peter.Marko@siemens.com>>
Sent: Thursday, February 26, 2026 6:47 PM
To: Het Patel -X (hetpat - E INFOCHIPS PRIVATE LIMITED at Cisco) <hetpat@cisco.com<mailto:hetpat@cisco.com>>; openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org> <openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>>
Cc: xe-linux-external(mailer list) <xe-linux-external@cisco.com<mailto:xe-linux-external@cisco.com>>; Viral Chavda (vchavda) <vchavda@cisco.com<mailto:vchavda@cisco.com>>
Subject: RE: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to exclude false positives




> -----Original Message-----
> From: openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org> <openembedded-
> core@lists.openembedded.org<mailto:core@lists.openembedded.org>> On Behalf Of Het Patel via
> lists.openembedded.org
> Sent: Thursday, February 26, 2026 13:54
> To: openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>
> Cc: xe-linux-external@cisco.com<mailto:xe-linux-external@cisco.com>; vchavda@cisco.com<mailto:vchavda@cisco.com>
> Subject: [OE-core] [PATCH v1] util-linux: Add vendor to CVE_PRODUCT to
> exclude false positives
>
> From: Het Patel <hetpat@cisco.com<mailto:hetpat@cisco.com>>
>
> - Added the vendor to CVE_PRODUCT to prevent false positives.
>
> Signed-off-by: Het Patel <hetpat@cisco.com<mailto:hetpat@cisco.com>>
> ---
>  meta/recipes-core/util-linux/util-linux.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-
> linux/util-linux.inc
> index deb9bfd064..81fefa5afa 100644
> --- a/meta/recipes-core/util-linux/util-linux.inc
> +++ b/meta/recipes-core/util-linux/util-linux.inc
> @@ -24,4 +24,4 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/util-
> linux/v${MAJOR_VERSION}/util-lin
>
>  SRC_URI[sha256sum] =
> "3330d873f0fceb5560b89a7dc14e4f3288bbd880e96903ed9b50ec2b5799e58b"
>
> -CVE_PRODUCT = "util-linux"
> +CVE_PRODUCT = "kernel:util-linux"

Which false positives are you trying to remove?
I think that all of these are correct and there are not false positives:

sqlite> select count(*), vendor, product from products where product like '%util-linux%' group by vendor, product;
29|andries_brouwer|util-linux
16|kernel|util-linux
56|linux|util-linux
1|util-linux_project|util-linux

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