Update NEWS entry: CVE-2020-36403 affected all older versions of HTSlib #1447
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
PR #1311 trusted the analysis in google/oss-fuzz-vulns's vulns/htslib/OSV-2020-955.yaml as to what HTSlib versions were affected by CVE-2020-36403:
It is accurate that the issue was fully fixed in dcd4b73, but the identified “introduced” commit dd6f0b7 is spurious and unrelated.
It turns out that the fuzz testing's test data file also has an invalid
#CHROMline which resulted in an error message in HTSlib versions ≤1.9:This error message and early exit masked the segfault caused by the actual issue, namely a VCF record whose in-memory representation requires more than 2GiB. Hence the fuzzing harness incorrectly concluded that versions ≤1.9 were unaffected by the issue.
The attached gen-huge-vcf.pl script generates an otherwise clean VCF file that exhibits the “record needs more than 2 GiB in memory” problem. This segfaults all the way back to HTSlib 1.0:
Thus all versions of HTSlib prior to the fixes in 1.11 were susceptible to this issue. This is unsurprising as, prior to the check added in PR #1044, the
ks_resize()code was unchanged since the beginning.