fix(targa): reject implausible image dimensions before allocating#5293
Merged
Merged
Conversation
An 18-byte TGA file consisting of just a header (no pixel data) can claim an arbitrary width/height/bpp -- e.g. a 1472x12000 24bpp image -- and readimg() would allocate the full ~53MB buffer and only discover the truncation once the first read hits EOF. Worse, the resulting partially-formed ImageSpec could still propagate to a downstream writer before the read failure was acted on. Cross-check the header's width/height/bpp against how many bytes of pixel data the file could plausibly contain before committing to the allocation, mirroring the existing pattern in iff.imageio and jpeg2000.imageio. The check compares against the *on-disk* pixel size (palette/16-bit storage is smaller per pixel than the decoded, unpacked ImageSpec) and allows up to 128x expansion for RLE-compressed images (a 1-byte run-length count can encode up to 128 output pixels). Updated testsuite/targa/ref/out.txt: several existing corrupt-file regression cases (crash1.tga, crash6.tga, crash3952.tga) are now caught earlier with clearer messages, and two real oiio-images TGA files (UCM8.TGA, UTC16.TGA) that use palette/16-bit storage smaller than their decoded size continue to read correctly. Assisted-by: Claude Code / Sonnet 5 Signed-off-by: Larry Gritz <lg@larrygritz.com>
jessey-git
approved these changes
Jul 4, 2026
jessey-git
left a comment
jessey-git
left a comment
Contributor
There was a problem hiding this comment.
Should be safe to do.
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
2 participants
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.
An 18-byte TGA file consisting of just a header (no pixel data) can claim an arbitrary width/height/bpp -- e.g. a 1472x12000 24bpp image -- and readimg() would allocate the full ~53MB buffer and only discover the truncation once the first read hits EOF. Worse, the resulting partially-formed ImageSpec could still propagate to a downstream writer before the read failure was acted on.
Cross-check the header's width/height/bpp against how many bytes of pixel data the file could plausibly contain before committing to the allocation, mirroring the existing pattern in iff.imageio and jpeg2000.imageio. The check compares against the on-disk pixel size (palette/16-bit storage is smaller per pixel than the decoded, unpacked ImageSpec) and allows up to 128x expansion for RLE-compressed images (a 1-byte run-length count can encode up to 128 output pixels).
Updated testsuite/targa/ref/out.txt: several existing corrupt-file regression cases (crash1.tga, crash6.tga, crash3952.tga) are now caught earlier with clearer messages, and two real oiio-images TGA files (UCM8.TGA, UTC16.TGA) that use palette/16-bit storage smaller than their decoded size continue to read correctly.
Assisted-by: Claude Code / Sonnet 5