The glibc package generates its own version number for glibc. It seems to be on purpose but this causes issues when matching versions against the official glibc releases. The version generated for 2023.08 seems to be 'glibc:2.37-2-g9f8513dc64119a424b312db97cef5d87d376defa' even though the glibc project only released 2.37. For tracking package versions used in a buildroot build we use 'make show-info'. This generates a json blob containing all information about packages, including a CPE string. For glibc in 2023.08 this creates the following CPE string: 'cpe:2.3:a:gnu:glibc:2.37-2-g9f8513dc64119a424b312db97cef5d87d376defa:*:*:*:*:*:*:*' This string does not match any known CVE security vulnerabilities. All reported vulnerabilities are reported with the version number 2.37 (without the number of commits since & hash). There's probably a reason why buildroot has deviated from the glibc reported version number & the versions used by the NIST that i'm not seeing, but this makes the CPE export and subsequent security analysis unusable for glibc.
This CPE id is generated based on GLIBC_VERSION, in package/glibc/glibc.mk: GLIBC_VERSION = 2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701 So indeed, the CPE id version field is 2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701. glibc.mk should probably do: GLIBC_CPE_ID_VERSION = 2.38 so that the CPE id has 2.38 has the version, allowing correct matching with the NIST database. *However*, this still will not give the correct results. Indeed, the matching with NIST database will be done assuming we use 2.38, so it will report all CVEs that affect the original 2.38 release. But Buildroot is not using 2.38, but 2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701, which is 27 commits above 2.38. This means that all CVEs fixed in those 27 commits will be reported by this matching process, even if they are not applicable, because we already have the fixes. One option of course is to add GLIBC_IGNORE_CVES entries for those CVEs so that they are ignored. But normally, we use that to ignore CVEs because they are fixed by local patches, or because they are not applicable to the Buildroot use-case/situation. It is a bit weird to have a GLIBC_IGNORE_CVES for a CVE that in fact does not affect the version that we use. But admittedly, it would be a valid entry for the version documented by GLIBC_CPE_ID_VERSION. So in other words, my proposal would be: - GLIBC_CPE_ID_VERSION = 2.38 - Addition of GLIBC_IGNORE_CVES entries for all CVEs fixed between 2.38 and 2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701
Peter, All, As for the reason why we use such a version string, one can read the fine details in that very good (as usual) LWN article; it dates back 4 years now, but the reasons are still the same, and boils down to the fact that glibc does not do dot-releases: https://lwn.net/Articles/736429/ So, rather than backport all and every patch going on the maintenance branch, we sinply choose the latest commit on said branch whenever there is a reason to update the version. I understand that this does not help with CPE/CVE identification, but as Thomas points out, we have a way out, something along the lines of: GLIBC_VERSION_MAJOR = 2.38 GLIBC_VERSION_MINOR = 27-g750a45a783906a19591fb8ff6b7841470f1f5701 GLIBC_VERSION = $(GLIBC_VERSION_MAJOR)-$(GLIBC_VERSION_MINOR) GLIBC_CPE_ID_VERSION = $(GLIBC_VERSION_MAJOR) # CVE-YYYY-XXXXXX fixed in [sha1 of commit fix] GLIBC_IGNORE_CVES += CVE-YYYY-XXXXX # CVE-YYYY-XXXXXX fixed in [sha1 of commit fix] GLIBC_IGNORE_CVES += CVE-YYYY-XXXXX and so on... It is indeed a bit tedious, but we have to play with whatever cards upstream dealt us; in this case, no dot-release. It would be awesome if you were willing to submit such a patch! Regards, Yann e. MORIN.
I have submitted a small series at https://patchwork.ozlabs.org/project/buildroot/list/?series=387611 that addresses this.
Thank you for your report. The issue tracker for the Buildroot project has been moved to the Gitlab.com issue tracker: https://gitlab.com/buildroot.org/buildroot/-/issues We are taking this opportunity to close old issues in this old tracker. If you believe your issue is still relevant, please open one in the new issue tracker. Thank you!