The repo caching validates repos are usable for tag to commit mapping (i.e. they have tags) before adding them.
It's possible that a CVE has a commit reference for a repo with no tags (but it's usable as-is because we assume the commit is a Fixed commit).
These repos were not being added to the repo cache, but the repo cache was being used as a short cut by subsequent calls to ReposFromReferences(), overwriting the internal state on what repos were known for a CVE with multiple CPEs.
This meant that for CVE-2024-45313, which has multiple CPE entries:
the Fixed commit was being extracted as a reference (as desired)
the full set of known repos was not being cached
the versions also extracted didn't resolve (as can happen)
the CVE was being rejected as having no Fixed commits (because these are searched for repo, from the set of expected repos, which was being overwritten by the cache hit on the second iteration through the CPEs)
This meant that CVE-2024-45313 initially successfully converted before the NVD analyzed it, but started failing to convert after the NVD added CPEs.
The repo caching validates repos are usable for tag to commit mapping (i.e. they have tags) before adding them.
It's possible that a CVE has a commit reference for a repo with no tags (but it's usable as-is because we assume the commit is a Fixed commit).
These repos were not being added to the repo cache, but the repo cache was being used as a short cut by subsequent calls to
ReposFromReferences(), overwriting the internal state on what repos were known for a CVE with multiple CPEs.This meant that for CVE-2024-45313, which has multiple CPE entries:
Fixedcommit was being extracted as a reference (as desired)This meant that CVE-2024-45313 initially successfully converted before the NVD analyzed it, but started failing to convert after the NVD added CPEs.