When multi-iterating CRAM files, hts_itr_multi_next() tries to calculate the chr:start-end range so that the multi-threaded CRAM decoder does not do unnecessary work. If it finds that the iterator is going to switch to another reference, this optimisation gets turned off and the end limit is ignored.
Unfortunately, the original version of this code, added in commit d3147150, did not disable the end point update after it had detected a switch to a different reference. This could lead to an out-of-bounds read because it did not switch to the correct intervals array for the later references. The end values looked up in that case were not used, but it could cause a segfault if the later references had many more intervals requested than the first one. Fix by only updating end when on the correct reference.
When multi-iterating CRAM files,
hts_itr_multi_next()tries to calculate thechr:start-endrange so that the multi-threaded CRAM decoder does not do unnecessary work. If it finds that the iterator is going to switch to another reference, this optimisation gets turned off and the end limit is ignored.Unfortunately, the original version of this code, added in commit d3147150, did not disable the end point update after it had detected a switch to a different reference. This could lead to an out-of-bounds read because it did not switch to the correct intervals array for the later references. The end values looked up in that case were not used, but it could cause a segfault if the later references had many more intervals requested than the first one. Fix by only updating
endwhen on the correct reference.This bug is present in releases 1.11 to 1.20
Fixes samtools/samtools#2063