Out-of-memory with ~40 bytes input file.

msarett@, scroggo@, as OWNERS of third_party/libpng, could you please help to find an owner for this?

The attached image indicates that it has width=801537, height=6.

We try to allocate memory in order to decode because this is within the default max sizes set by libpng.  Note that these Chrome setting match the libpng default.
#define PNG_USER_HEIGHT_MAX 1000000
#define PNG_USER_WIDTH_MAX 1000000
https://cs.chromium.org/chromium/src/third_party/libpng/pnglibconf.h?l=210

We *could* make these max values smaller - but then we might fail to decode an image that we should be able decode.

FWIW, libpng recommends W=65535, H=65535 as "safe settings" if we want to override the default.  I'm not sure this makes sense either.  It would be possible to craft an image that falls within the safe settings, but is still larger than the one in this bug.
https://github.com/glennrp/libpng/blob/libpng16/pngusr.dfa

I believe that trying to allocate (and possibly running OOM) on really larger images is a known behavior in Chrome.

I think one approach to solving this is to check the image dimensions before decoding, and then requesting a scaled decode if the image is very large.  There are a few bugs discussing this idea:
https://bugs.chromium.org/p/chromium/issues/detail?id=438323
https://bugs.chromium.org/p/chromium/issues/detail?id=558070

We have some sanity check in the fuzzer: https://cs.chromium.org/chromium/src/testing/libfuzzer/fuzzers/libpng_read_fuzzer.cc?q=libpng_read&sq=package:chromium&l=91

Should we harden that like "if (height > 65535 || width > 65535) { return 0;}"?

I'm not exactly sure what the common practice is in this case.  I'll defer to your opinion.

Another option would be to lower the limit for the maximum size of width * height (Ex: width * height > CONSTANT).

It's hard to say what's best.  Reducing that limit means that the fuzzer covers less cases.  On some machines this may make sense (since we'll run OOM anyway), on others though, it might mean missing out on testing an interesting case.

Maybe we should lower PNG_USER_HEIGHT_MAX in the fuzzer builds 
instead so that we hit the hard limit, not the soft limit. 

c#6 seems to be a good idea! We hit that OOM only for MSan build (https://cluster-fuzz.appspot.com/fuzzerstats?fuzzer_name=libfuzzer_libpng_read_fuzzer&job_type=all&last_n=30&last_n_type=days&group_by=job), so we can re-define the hard limit in GN only for is_msan=true.

defines = [] didn't help, since pnglibconf.h is being processed after them and re-defines default values again, but there is png_set_user_limits() function that looks convenient to me: https://codereview.chromium.org/2377293002

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4890882858024960

Fuzzer: libfuzzer_libpng_read_fuzzer
Job Type: libfuzzer_chrome_msan
Platform Id: linux

Crash Type: Out-of-memory
Crash Address: 
Crash State:
  libpng_read_fuzzer
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_msan&range=399437:399478

Minimized Testcase (0.04 Kb): https://cluster-fuzz.appspot.com/download/AMIfv954FW7Y2LF4crMVM_y7bIv-yPlUemffBX_P4clxQUZWmFJ9Cut5VbWsSfFZDNFeqAooptsPM400qXYmFcyo8lna0NxPvl0e4ddslwqNI-D269FsPfgtE0MroS3uXHkPgpJ1Ci2hZA0IEwa8RHeudf3S50Slkg?testcase_id=4890882858024960

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

ClusterFuzz has detected this issue as fixed in range 423173:423231.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4890882858024960

Fuzzer: libfuzzer_libpng_read_fuzzer
Job Type: libfuzzer_chrome_msan
Platform Id: linux

Crash Type: Out-of-memory
Crash Address: 
Crash State:
  libpng_read_fuzzer
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_msan&range=399437:399478
Fixed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_msan&range=423173:423231

Minimized Testcase (0.04 Kb): https://cluster-fuzz.appspot.com/download/AMIfv954FW7Y2LF4crMVM_y7bIv-yPlUemffBX_P4clxQUZWmFJ9Cut5VbWsSfFZDNFeqAooptsPM400qXYmFcyo8lna0NxPvl0e4ddslwqNI-D269FsPfgtE0MroS3uXHkPgpJ1Ci2hZA0IEwa8RHeudf3S50Slkg?testcase_id=4890882858024960

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.

Fixed by https://codereview.chromium.org/2377293002/

But that's still interesting, why libpng with MSan eats so many memory for ~5 Megapixel image.

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

commit 0ceee9d387bb17c24adefffd9927ebaf68a3df1f
Author: mmoroz <mmoroz@chromium.org>
Date: Wed Oct 05 17:40:57 2016

[libfuzzer] libpng_read_fuzzer: call png_set_user_limits() for MSan.

To avoid OOM with MSan ( crbug.com/648073 ). These values are recommended as
safe settings by https://github.com/glennrp/libpng/blob/libpng16/pngusr.dfa

R=aizatsky@chromium.org, msarett@chromium.org
BUG= 648073 

Review-Url: https://codereview.chromium.org/2377293002
Cr-Commit-Position: refs/heads/master@{#423208}

[modify] https://crrev.com/0ceee9d387bb17c24adefffd9927ebaf68a3df1f/testing/libfuzzer/fuzzers/libpng_read_fuzzer.cc

[Automated comment] removing mislabelled merge-merged-2840

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

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