-
Notifications
You must be signed in to change notification settings - Fork 0
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 several overflows in box and track processing #2
base: master
Are you sure you want to change the base?
Conversation
47d26a0
to
241b9d6
Compare
241b9d6
to
686a7a3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM now!
This appears to be a bug unmasked by other changes. read_sample() calls sample_offset() then sample_size(), and assumes that if the former returns Ok then the latter does as well. However, if the sample_id is one past the end, sample_offset() might succeed (it only checks samples _up to_ the given sample_id but not _including_ it) while sample_size() fails (because the sample doesn't exist). read_sample() will then panic. Fix this by duplicating the error propagation (that is currently done for sample_offset) for sample_size, instead of unwrapping. This is a cautious change that fixes the bug; alternatively, having sample_offset() call sample_size() on the given sample_id and propagate any error might also work.
930c9ee
to
57173ce
Compare
Together with the entry_count checks, this eliminates several OOMs when reading incorrect mp4 files.
@@ -103,6 +103,11 @@ impl<R: Read + Seek> ReadBox<&mut R> for Avc1Box { | |||
|
|||
let header = BoxHeader::read(reader)?; | |||
let BoxHeader { name, size: s } = header; | |||
if s > size { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose we could be more precise here (and below), with:
if s > size.saturating_sub(reader.stream_position() - start) {
Do you think it's worth it to do so? Maybe not, since I think these checks are mostly to prevent crashes due to large allocations, right? In that case, maybe add comments explaining why the checks are imprecise.
This also makes me realize that pretty much every read_box
should be doing:
let mut reader = reader.take(size - HEADER_SIZE);
so that they don't read past the end of the box. But I can file a bug (#4) for that to do in a separate PR (since this one is getting large).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I seem to remember that this/something else already effectively prevented that sort of box overrun? I'll take another look, though; if that's not the case, I'll open another PR for #4.
This was due to an incorrect transcription when switching to checked arithmetic, and fixes a bug that could cause attempted lookups of the wrong chunk_id.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
No description provided.