Unable to provide possible suspect using Predator, CL and Code Search.
Could someone please look into the issue.


Thank You...

rharrison: Got time for this one?

Not immediately, but given it is XFA specific it should probably be in my work queue.

Started looking at this a bit. Looks like the file is malformed and the codec is scanning ahead looking for where to start decoding after the header. 

For some reason this is causing a large memory hit. I am going to need to investigate more, since what I would expect is that even if it has to scan the entire file to determine there is no beginning it shouldn't use 2 gigs. The file is only ~600kB. 

It is actually making progress on the scan, but it is very costly. The codec isn't getting stuck in a loop or something loading the same chunk repreatedly from what I can tell.

I have root caused this to the PDFium code incorrectly continuing after receiving a signal that indicates a fatal error in the jpeg decode.

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium/+/b73a96938d0fc932a9d498359c98f4cf6ef34160

commit b73a96938d0fc932a9d498359c98f4cf6ef34160
Author: Ryan Harrison <rharrison@chromium.org>
Date: Wed Jan 17 18:12:16 2018

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>

[modify] https://crrev.com/b73a96938d0fc932a9d498359c98f4cf6ef34160/core/fxcodec/codec/fx_codec_jpeg.cpp
[modify] https://crrev.com/b73a96938d0fc932a9d498359c98f4cf6ef34160/core/fxcodec/codec/ccodec_jpegmodule.h
[modify] https://crrev.com/b73a96938d0fc932a9d498359c98f4cf6ef34160/core/fxcodec/codec/fx_codec_progress.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/235f0501ca6675c678d446400929ffb10e6c6088

commit 235f0501ca6675c678d446400929ffb10e6c6088
Author: pdfium-deps-roller@chromium.org <pdfium-deps-roller@chromium.org>
Date: Wed Jan 17 20:40:33 2018

Roll src/third_party/pdfium/ f85548979..b73a96938 (2 commits)

https://pdfium.googlesource.com/pdfium.git/+log/f855489794ff..b73a96938d0f

$ git log f85548979..b73a96938 --date=short --no-merges --format='%ad %ae %s'
2018-01-17 rharrison Correctly handle errors when starting jpeg codec
2018-01-17 hnakashima Pass ios_base::binary so WriteBitmapToPng works on Windows.

Created with:
  roll-dep src/third_party/pdfium
BUG= 798665 


The AutoRoll server is located here: https://pdfium-roll.skia.org

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.


TBR=dsinclair@chromium.org

Change-Id: I604d83fd3348b2d691a6b75f6aee5e296db3a6e8
Reviewed-on: https://chromium-review.googlesource.com/871043
Reviewed-by: <pdfium-deps-roller@chromium.org>
Commit-Queue: <pdfium-deps-roller@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529872}
[modify] https://crrev.com/235f0501ca6675c678d446400929ffb10e6c6088/DEPS

ClusterFuzz has detected this issue as fixed in range 529850:529892.

Detailed report: https://clusterfuzz.com/testcase?key=4570492366487552

Fuzzer: libFuzzer_pdf_codec_jpeg_fuzzer
Job Type: libfuzzer_chrome_msan
Platform Id: linux

Crash Type: Out-of-memory (exceeds 2048 MB)
Crash Address: 
Crash State:
  pdf_codec_jpeg_fuzzer
  
Sanitizer: memory (MSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=398314:399191
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=529850:529892

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4570492366487552

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 4570492366487552 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.