summaryrefslogtreecommitdiff
path: root/fxbarcode/oned/BC_OnedCode39Writer_unittest.cpp
diff options
context:
space:
mode:
authorRyan Harrison <rharrison@chromium.org>2018-01-17 18:12:16 +0000
committerChromium commit bot <commit-bot@chromium.org>2018-01-17 18:12:16 +0000
commitb73a96938d0fc932a9d498359c98f4cf6ef34160 (patch)
tree9223a1b178dc7ceedff28dd96df294d3f3eaddca /fxbarcode/oned/BC_OnedCode39Writer_unittest.cpp
parent6d6a243893532de40f636dbdc61d10c04ab019fb (diff)
downloadpdfium-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