This may be another case of  bug 761005 .

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

commit b6e0117285a918f4f2f3a350b8a648d2247d3d8e
Author: Ryan Harrison <rharrison@chromium.org>
Date: Wed Jun 20 13:43:04 2018

Add in a size guard to JPX fuzzer

Setting an upper limit to the size of images being processed in the
JPX fuzzer to reduce timeouts due to images just being really big.

Also cleaned the types for passing pitch down to reduce the signedness
conversions.

BUG= chromium:834561 

Change-Id: I28b7a2537a922ed7a9ca2f8ed049ae78dd471f49
Reviewed-on: https://pdfium-review.googlesource.com/35570
Reviewed-by: Henrique Nakashima <hnakashima@chromium.org>
Commit-Queue: Ryan Harrison <rharrison@chromium.org>

[modify] https://crrev.com/b6e0117285a918f4f2f3a350b8a648d2247d3d8e/core/fxcodec/codec/ccodec_jpxmodule.h
[modify] https://crrev.com/b6e0117285a918f4f2f3a350b8a648d2247d3d8e/core/fxcodec/codec/fx_codec_jpx_opj.cpp
[modify] https://crrev.com/b6e0117285a918f4f2f3a350b8a648d2247d3d8e/core/fxcodec/codec/cjpx_decoder.h
[modify] https://crrev.com/b6e0117285a918f4f2f3a350b8a648d2247d3d8e/testing/fuzzers/pdf_jpx_fuzzer.cc

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

commit ab1e7538f947ae196b192d9af73ce16cb131748f
Author: pdfium-chromium-autoroll <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Date: Wed Jun 20 15:25:29 2018

Roll src/third_party/pdfium e005dc33c31a..b6e0117285a9 (1 commits)

https://pdfium.googlesource.com/pdfium.git/+log/e005dc33c31a..b6e0117285a9


git log e005dc33c31a..b6e0117285a9 --date=short --no-merges --format='%ad %ae %s'
2018-06-20 rharrison@chromium.org Add in a size guard to JPX fuzzer


Created with:
  gclient setdep -r src/third_party/pdfium@b6e0117285a9

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.



BUG= chromium:834561 
TBR=dsinclair@chromium.org

Change-Id: I4ac1250c2e205994b6594b5a06bb34e6bd07e7fc
Reviewed-on: https://chromium-review.googlesource.com/1107938
Reviewed-by: pdfium-chromium-autoroll <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Commit-Queue: pdfium-chromium-autoroll <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#568849}
[modify] https://crrev.com/ab1e7538f947ae196b192d9af73ce16cb131748f/DEPS

ClusterFuzz testcase 6696255098191872 is still reproducing on tip-of-tree build (trunk).

Please re-test your fix against this testcase and if the fix was incorrect or incomplete, please re-open the bug. Otherwise, ignore this notification and add ClusterFuzz-Wrong label.

Apparently the JPX decoding path feels the need to decompress the entire image as part of ::Init, ::Decode doing the translation into the bitmap data structure thing... Thus why my check is not working, since on creation of the decoder we are blowing the memory limit.

I am getting deja vu about this, I feel like I have looked at this previously. I am not sure if it was in the JPX code or in the JPEG code.

This is the same basic issue. The JPX code is inflating the image during the init code, so we cannot easily guard against too large images. We need to break up reading the header and inflating the image into two separate chunks. I have failed to do this once already in the past.

ClusterFuzz has detected this issue as fixed in range 600184:600189.

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

Fuzzer: libFuzzer_pdf_jpx_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: Out-of-memory (exceeds 2048 MB)
Crash Address: 
Crash State:
  pdf_jpx_fuzzer
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=499756:499820
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=600184:600189

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

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.

PartitionAlloc update broke the fuzzer.