Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix possible out-of-bounds read in hts_itr_multi_next() (CRAM only) #1788

Merged
merged 2 commits into from
Jun 6, 2024

Conversation

daviesrob
Copy link
Member

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 d314715, 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.

This bug is present in releases 1.11 to 1.20

Fixes samtools/samtools#2063

daviesrob added 2 commits May 31, 2024 14:41
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 d314715, 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.

This bug is present in releases 1.11 to 1.20
Add a multi-region iterator look-up on range.cram, with one
CHROMOSOME_I region and enough CHROMOSOME_II to trigger the
bug on the unfixed version of the function.
@jkbonfield jkbonfield merged commit 5f20533 into samtools:develop Jun 6, 2024
9 checks passed
@daviesrob daviesrob deleted the samtools_2063_fix branch June 11, 2024 15:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants