xpdf issues being blamed on freetype
- Dominant language
- Shell
- Stars
- 12.6k
- Forks
- 2.9k
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 62
Description
Consider xpdf issues [42534869](https://issues.oss-fuzz.com/issues/42534869), [42534625](https://issues.oss-fuzz.com/issues/42534625), and [42534827](https://issues.oss-fuzz.com/issues/42534827). These are all being blamed on freetype, for example see [OSV-2024-963.yaml](https://github.com/google/oss-fuzz-vulns/blob/main/vulns/xpdf/OSV-2024-963.yaml) which is reported as [OSV-2024-963](https://osv.dev/vulnerability/OSV-2024-963). The issue here appears to be that xpdf does not have a repo [see Dockerfile](https://github.com/google/oss-fuzz/blob/master/projects/xpdf/Dockerfile) and in fact provides no indication of which version is actually being fuzzed, so there is no information to even pass on for xpdf. However, because freetype is checked out it appears to be blamed as a bystander for all of xpdfs issues, since it is the only "repo" available. I cannot see the detailed reports for these issues, but none of the stacks appear to have anything to do with freetype, and the freetype range on these does not look like it makes much sense.
It isn't entirely clear if this needs to be fixed in oss-fuzz or oss-fuzz-vulns. It looks like the bisect information is from oss-fuzz, which might be blaming the wrong project due to the fact that xpdf doesn't have a main repo (it's just a .tar.gz being downloaded without any version information).
Contributor guide
Assessment
This issue has not been assessed yet.