Conversation
Strips compressed with LZW were read with an oversized limit, width*height*8, enough for RGBA64, so decoding kept demanding data past the point where a strip's pixels were already fully decoded. Whatever followed, end of input or a code the LZW dictionary hadn't defined yet, turned into unexpected EOF or lzw: invalid code, discarding a strip that had already decoded correctly. Compute the exact number of bytes a block needs from its width, height, samples per pixel and bits per sample, and use that as the read limit instead, falling back to the old bound when it can't be computed. decode already reports "not enough pixel data" for a block that comes back short, so a genuinely truncated strip is still caught. The same over-read is possible for the other compressions still on the old bound; this only touches LZW, the one actually observed and tested here. Fixes golang/go#81347
Contributor
|
This PR (HEAD: 8800f93) has been imported to Gerrit for code review. Please visit Gerrit at https://go-review.googlesource.com/c/image/+/828484. Important tips:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.Suggestion cannot be applied right now. Please check back later.
tiff: limit LZW block reads to the block's exact size
Strips compressed with LZW were read with an oversized limit,
widthheight8, enough for RGBA64, so decoding kept demanding data
past the point where a strip's pixels were already fully decoded.
Whatever followed, end of input or a code the LZW dictionary hadn't
defined yet, turned into unexpected EOF or lzw: invalid code,
discarding a strip that had already decoded correctly.
Compute the exact number of bytes a block needs from its width,
height, samples per pixel and bits per sample, and use that as the
read limit instead, falling back to the old bound when it can't be
computed. decode already reports "not enough pixel data" for a block
that comes back short, so a genuinely truncated strip is still caught.
The same over-read is possible for the other compressions still on
the old bound; this only touches LZW, the one actually observed and
tested here.
Fixes golang/go#81347