Is the cve-check.bblass supposed to include REJECTED CVEs? This turned up while playing with the Yocto-CVE-Parser and some master branch: https://github.com/ejaaskel/Yocto-CVE-Parser/issues/4#issuecomment-2493046767
It used to work, looks like a regression.
However, an entry without CVSS at all is a valid one.
It's supposed to work. Code is here: meta/recipes-core/meta/cve-update-nvd2-native.bb: https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/meta/cve-update-nvd2-native.bb?h=master#n339 I'll try to look at this one.
(In reply to Robert Berger from comment #0) > Is the cve-check.bblass supposed to include REJECTED CVEs? > > This turned up while playing with the Yocto-CVE-Parser and some master > branch: > > https://github.com/ejaaskel/Yocto-CVE-Parser/issues/4#issuecomment-2493046767 I've tried with a full download of the NVD data. From the list of problematic CVEs in the above link, only CVE-2023-4134 is present. CVE-2023-4134 is not Rejected, maybe it's an error? That CVE aside, Rejected CVEs look correctly removed for the database during the full-download. What could have happen is that the NVD recently had a glitch (approximately the same time as this bug was reported). Maybe the update marking these CVEs "Rejected" failed and the previous "active" state was kept? @Robert, does it sound plausible?
Turns out that when building the latest version of the Poky, there are rejected CVEs in the report, and they don't have a severity score assigned to them. Examples issues don't have a score assigned to them and were included in the summary (built from Poky master hash 273eb505cb11fbe0590da9c8fc06c76b4405bf8c): CVE-2021-36217 CVE-2024-35325 CVE-2024-35326 CVE-2024-35328 CVE-2017-0605 CVE-2017-1000 CVE-2019-10124 CVE-2019-3892 CVE-2019-9457 CVE-2019-9466 CVE-2020-0255 CVE-2020-0435 CVE-2020-14353 CVE-2021-0447 CVE-2021-0448 CVE-2021-0937 CVE-2021-3587 CVE-2021-3894 CVE-2021-3896 CVE-2022-0644 CVE-2022-1836 CVE-2022-1966 CVE-2022-1972 CVE-2022-20424 CVE-2022-20565 CVE-2022-21505 CVE-2022-23816 CVE-2022-3522 CVE-2022-3531 CVE-2022-3532 CVE-2022-3535 CVE-2022-3542 CVE-2023-0047 CVE-2023-2248 CVE-2023-2483 CVE-2023-3117 CVE-2023-34255 CVE-2023-3865 CVE-2023-3866 CVE-2023-3867 CVE-2023-4128 CVE-2023-4134 CVE-2023-4563 CVE-2023-4610 CVE-2023-4881 CVE-2023-52575 CVE-2023-52630 CVE-2024-0584 CVE-2024-26639 CVE-2024-26650 What should the cve report created by the YP do with them by design? --- If it's what you say, that the NVD recently had a glitch (approximately the same time as this bug was reported) - which is unlikely, since I built it a couple of times and someone else as well a couple of days later. We have a serious problem! Maybe the update marking these CVEs "Rejected" failed and the previous "active" state was kept? With my current build I don't see this issue anymore.
Wouldn't it be possible to add something like a checksum to the database fetch? So we can see that it's invalid?
Ross to add a comment.
It looks like if we already have a CVE in our database but in an update later changes it to rejected, it will still be reported because we filter out rejected CVEs too early. Note that the NVD database is basically useless at this point in time, so whilst we should fix this there are far bigger problems...
Obsolete, cve-check has been removed from 6.0.