diff options
author | Ryan Harrison <rharrison@chromium.org> | 2018-01-17 18:12:16 +0000 |
---|---|---|
committer | Chromium commit bot <commit-bot@chromium.org> | 2018-01-17 18:12:16 +0000 |
commit | b73a96938d0fc932a9d498359c98f4cf6ef34160 (patch) | |
tree | 9223a1b178dc7ceedff28dd96df294d3f3eaddca /fxbarcode/oned/BC_OnedCode39Writer_unittest.cpp | |
parent | 6d6a243893532de40f636dbdc61d10c04ab019fb (diff) | |
download | pdfium-b73a96938d0fc932a9d498359c98f4cf6ef34160.tar.xz |
Correctly handle errors when starting jpeg codec
The current implementation treats both returning false and longjmp'ing
out of jpeg_start_decompress as indicating that the decompression has
paused and needs more data. This is incorrect, in reality only the
false return value indicates this. The longjmp path indicates a fatal
error in the processing of the jpeg. The default implementation
actually calls exit() in this case, and the documentation explicitly
calls out that in this case recovery isn't possible and the decode
process will have to start from scratch.
This resolves a situation where the progressive decoder would get a
malformed jpeg and keep on grabbing blocks from it and try to start
decoding it. This would eventually fail when it ran out of data to
read, but would cause a large memory leak and a crash on the MSAN
fuzzers.
BUG=pdfium:986,chromium:798665
Change-Id: Ifd2ed7a2dc46fa20bab34e9c461a8d4c4718c4d7
Reviewed-on: https://pdfium-review.googlesource.com/23072
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Diffstat (limited to 'fxbarcode/oned/BC_OnedCode39Writer_unittest.cpp')
0 files changed, 0 insertions, 0 deletions