TIFF: prevent integer overflow when reading from a large tile #3519
Conversation
When reading from a single tile whose byte count is > 2GB, use "seek" instead of "skipBytes" to prevent a possible integer overflow.
| @@ -1026,7 +1026,9 @@ else if (stripByteCounts[countIndex] < 0 && countIndex > 0) { | |||
| // we only want a piece of the tile, so read each row separately | |||
| // this is especially necessary for large single-tile images | |||
| int bpp = bytes * effectiveChannels; | |||
| in.skipBytes((int) (y * bpp * tileWidth)); | |||
| // don't use skipBytes here, as the number of bytes to skip may | |||
| // be greater than Integer.MAX_VALUE if the tile is large | |||
There was a problem hiding this comment.
Forgot about that API method; fixed in b47dafa.
|
An artificial test file is now in To see the problem without this PR: The top portion of the image should show a gradient as expected, but the bottom portion will be oddly striped. With this PR, the same test should result in an image with a completely smooth gradient. |
|
Using the new sample file the behaviour can be easily reproduced and is visible across the different resolution levels. I couldn't find any obvious pattern in the starting point of the corruption though.
With the PR included the image is read and displayed without andy issues. There have been no regressions in any tests, merging this to included for 6.4.0 |
When reading from a single tile whose byte count is > 2GB,
use
seekinstead ofskipBytesto prevent a possible integer overflow./cc @chris-allan, @douglasrennick