diff options
author | Ryan Harrison <rharrison@chromium.org> | 2018-05-03 20:40:35 +0000 |
---|---|---|
committer | Chromium commit bot <commit-bot@chromium.org> | 2018-05-03 20:40:35 +0000 |
commit | ad178855775da18d7abfadce4b64825f3e32adbd (patch) | |
tree | 8709b39b40f676e25da4c08cd940c5dbb53848cd /tools | |
parent | e7f4d334eff7d396ec0043a97f751483f8cc9e75 (diff) | |
download | pdfium-ad178855775da18d7abfadce4b64825f3e32adbd.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 'tools')
0 files changed, 0 insertions, 0 deletions