Assigning to the concern owner as per the Code Search, "pdf_codec_tiff_fuzzer" who worked on similar issue.
@npm -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

Filed http://bugzilla.maptools.org/show_bug.cgi?id=2708, should probably wait for it to be fixed upstream.

http://bugzilla.maptools.org/show_bug.cgi?id=2708 fixed

Not fixed after applying upstream patches, will update bug upstream.

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

commit c3eca649ce2213b06551e8de8793e24ec6f9cef5
Author: Nicolas Pena <npm@chromium.org>
Date: Thu Jul 13 15:17:26 2017

Libtiff OOM upstream patch

This CL applies two upstream patches that help with OOM problems:
https://github.com/vadz/libtiff/commit/1077fad562e03d1cad591dd10163dd80ad63ab0e
https://github.com/vadz/libtiff/commit/0a619f1e553e46df8022b889ff44f8a1faa1e48d

These do not yet fix the bug below.

Bug:  chromium:718494 
Change-Id: If68c20f504b27c07dba2765f8e5ef708c1a54d7e
Reviewed-on: https://pdfium-review.googlesource.com/7731
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>

[modify] https://crrev.com/c3eca649ce2213b06551e8de8793e24ec6f9cef5/third_party/libtiff/tiffiop.h
[modify] https://crrev.com/c3eca649ce2213b06551e8de8793e24ec6f9cef5/third_party/libtiff/tif_getimage.c
[modify] https://crrev.com/c3eca649ce2213b06551e8de8793e24ec6f9cef5/third_party/libtiff/tif_read.c
[modify] https://crrev.com/c3eca649ce2213b06551e8de8793e24ec6f9cef5/third_party/libtiff/README.pdfium
[add] https://crrev.com/c3eca649ce2213b06551e8de8793e24ec6f9cef5/third_party/libtiff/0025-upstream-OOM-gtTileContig.patch

The OOM crash happens in 80% of fuzzer runs: https://clusterfuzz.com/v2/performance-report/libFuzzer_pdf_codec_tiff_fuzzer/libfuzzer_chrome_asan/latest

so let me make it Pri-1, since it's a blocker for gaining new coverage and efficient continuous testing

I've shared the testcase upstream because they have submitted patches to attempt to fix this but those patches haven't worked so far. LibTIFF is an old library, so it's full of places where mallocs are made without checking that the testcase will actually need all that space (and sometimes it may be nontrivial to do those checks). Fixing this testcase will probably not change the OOM percentage significantly (which by the way is really strange, considering about 80% are OOM and about 55% are crashes - I have no idea how that can possibly occur).

I think what would really be useful here is to allow de-duplicating OOM testcases when the OOM is caused by a sufficiently large malloc, for instance when the error is sent from Fuzzer::HandleMalloc (this testcase is one such example). In these cases, we have the stacktrace of the code where such malloc was requested, so it should work like it does for overflows and other types of bugs.

But anyways, I don't know if LibTIFF will ever be at a state where OOM testcases are not easy to create.

Nicolás, thanks for the detailed response! You're right about percentage of OOMs. I took another look at the logs and realized that there are lines like:

==17156:17156==WARNING: AddressSanitizer failed to allocate 0x115000000010000 bytes
==17156:17156==WARNING: AddressSanitizer failed to allocate 0x1000000010400 bytes
==17156:17156==WARNING: AddressSanitizer failed to allocate 0x1000301160000 bytes
==17156:17156==WARNING: AddressSanitizer failed to allocate 0x43ffffffbc2 bytes

which are warnings, not OOM crashes. Thanks for noticing that, I'll upload a fix for our stats calculation.


Regarding 55% of crashes, it's mostly  issue 743621  I think.

Resetting priority back to 2.

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

commit d4362fe972442cfd2d6aa9b32134240c0ddaa6c5
Author: Nicolas Pena <npm@chromium.org>
Date: Thu Jul 27 21:18:34 2017

Define SIZEOF_VOIDP and other cleanup in tiffconf

This CL uses sizeof to calculate sizes in tiffconf. It adds SIZEOF_VOIDP
to allow LibTIFF to take codepaths reducing OOMs. Finally, it gets rid
of _FX_WIN32_MOBILE_ since it's never defined.

Bug:  chromium:718494 
Change-Id: I9e6fb2812487ccd7d08e56fd1954c716ddccd07b
Reviewed-on: https://pdfium-review.googlesource.com/9410
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>

[modify] https://crrev.com/d4362fe972442cfd2d6aa9b32134240c0ddaa6c5/third_party/libtiff/tiffconf.h
[modify] https://crrev.com/d4362fe972442cfd2d6aa9b32134240c0ddaa6c5/third_party/libtiff/0000-build-config.patch
[delete] https://crrev.com/33805cc811c722a0c5cd439cff419de252cd39c9/third_party/libtiff/0001-build-config.patch
[modify] https://crrev.com/d4362fe972442cfd2d6aa9b32134240c0ddaa6c5/core/fxcrt/cfx_seekablestreamproxy.cpp
[modify] https://crrev.com/d4362fe972442cfd2d6aa9b32134240c0ddaa6c5/core/fxcrt/cfx_datetime.cpp

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

commit 6a5b7872c838ba9e24ea6e1f9a306bb95a80ae6c
Author: Nicolas Pena <npm@chromium.org>
Date: Thu Aug 03 20:44:41 2017

LibTIFF: fix defines in tiffconf

This CL hardcodes the defines  used in tiffconf so that the values can
be used inside of '#if'. The CL that changed them was:
https://pdfium-review.googlesource.com/c/9410

SIZEOF_VOIDP was a new variable in that CL. This CL uses __LP64__ to
detect whether this value should be set to 8 or to 4.

Bug:  chromium:718494 
Change-Id: I628d64cb7e2e94c47b8bcc1856abf5949d6578d4
Reviewed-on: https://pdfium-review.googlesource.com/10090
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>

[modify] https://crrev.com/6a5b7872c838ba9e24ea6e1f9a306bb95a80ae6c/third_party/libtiff/tiffconf.h
[add] https://crrev.com/6a5b7872c838ba9e24ea6e1f9a306bb95a80ae6c/third_party/libtiff/0027-build-config.patch
[modify] https://crrev.com/6a5b7872c838ba9e24ea6e1f9a306bb95a80ae6c/third_party/libtiff/README.pdfium

ClusterFuzz has detected this issue as fixed in range 491858:491939.

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

Fuzzer: libFuzzer_pdf_codec_tiff_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Out-of-memory (exceeds 2048 MB)
Crash Address: 
Crash State:
  pdf_codec_tiff_fuzzer
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=468576:468586
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=491858:491939

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


See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.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 4883692150587392 is verified as fixed, so closing issue as verified.

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