summaryrefslogtreecommitdiff
path: root/core/fdrm
diff options
context:
space:
mode:
authorRyan Harrison <rharrison@chromium.org>2018-05-03 20:40:35 +0000
committerChromium commit bot <commit-bot@chromium.org>2018-05-03 20:40:35 +0000
commitad178855775da18d7abfadce4b64825f3e32adbd (patch)
tree8709b39b40f676e25da4c08cd940c5dbb53848cd /core/fdrm
parente7f4d334eff7d396ec0043a97f751483f8cc9e75 (diff)
downloadpdfium-chromium/3419.tar.xz
Invalidate GIF input buffer when moving file cursor backwardschromium/3420chromium/3419
The current implementation of the GIF codec does not handle the file cursor moving backwards correctly. Specifically the input buffer that the data is being read into is not invalidated, so if the entirity of the buffer hasn't been consumed, a chunk of it will be moved to the front before reading in more data, which is just incorrect. Additionally, depending on the specific series of operations, it is possible that the buffer was allocated for more space then had been read into it and the uninitialized portion at the end is being copied to the beginning. The file cursor may move backwards when dealing with an animated gif or other image with multiple frames, since all of the control data is read in on load, and future calls specify what frame to fetch. The code has been changed to treat the input buffer as invalid when moving the cursor to a frame location, which will bypass any of the problematic unused saving behaviour. A call to std::min has been added to prevent allocation of an input buffer larger then the file size. Additionally this CL refactors GifReadMoreData to be clearer about what calculations are occuring, since the existing code reuses a number of vaguely named variables, making it difficult to follow. BUG=chromium:839348, chromium:839361 Change-Id: I2865658187bdf30bcad13ef4cac4f51a8966db11 Reviewed-on: https://pdfium-review.googlesource.com/32054 Reviewed-by: Henrique Nakashima <hnakashima@chromium.org> Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Diffstat (limited to 'core/fdrm')
0 files changed, 0 insertions, 0 deletions