Just noticed, that there was a more recent version available i.e. release 504516. I would like to confirm that the crash occurs in that one too.

Also this report is different from  crbug.com/765858  since this crash occurs after https://crrev.com/504281 (whose Log states that  crbug.com/765858  was fixed).

Also before any confusion arises, I would like to state that "NO RUN-TIME FLAG" was applied to reproduce this crash.

Thanks,
~ Kushal.

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=6149486165622784.

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

Job Type: linux_msan_filter_fuzz_stub
Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  read_header
  SkWbmpCodec::IsWbmp
  SkCodec::MakeFromStream
  
Sanitizer: memory (MSAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=linux_msan_filter_fuzz_stub&range=502343:502407

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

See https://github.com/google/clusterfuzz-tools for more information.

A recommended severity was added to this bug. Please change the severity if it is inaccurate.

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

I didn't quite follow the instructions for reproducing, but I was able to get a similar stack trace using Skia's own fuzzing tool:

ninja -C out/msan fuzz && ./out/msan/fuzz -t filter_fuzz -b <test_case>

Here is the report from msan:

Uninitialized bytes in __interceptor_memcmp at offset 0 inside [0x7ffca1c60860, 8)
==138378==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x1129c54 in png_sig_cmp /usr/local/google/skia/out/msan/../../third_party/externals/libpng/png.c:90:18
    #1 0x6082dd6 in SkPngCodec::IsPng(char const*, unsigned long) /usr/local/google/skia/out/msan/../../src/codec/SkPngCodec.cpp:321:13
    #2 0x287d117 in SkCodec::MakeFromStream(std::__1::unique_ptr<SkStream, std::__1::default_delete<SkStream> >, SkCodec::Result*, SkPngChunkReader*) /usr/local/google/skia/out/msan/../../src/codec/SkCodec.cpp:96:9
    #3 0x2885683 in SkCodec::MakeFromData(sk_sp<SkData>, SkPngChunkReader*) /usr/local/google/skia/out/msan/../../src/codec/SkCodec.cpp:126:12
    #4 0x7a6f5a3 in SkCodecImageGenerator::MakeFromEncodedCodec(sk_sp<SkData>) /usr/local/google/skia/out/msan/../../src/codec/SkCodecImageGenerator.cpp:12:18
    #5 0x297dad1 in SkImageGenerator::MakeFromEncodedImpl(sk_sp<SkData>) /usr/local/google/skia/out/msan/../../src/ports/SkImageGenerator_skia.cpp:12:12
    #6 0x1782125 in SkImageGenerator::MakeFromEncoded(sk_sp<SkData>) /usr/local/google/skia/out/msan/../../src/core/SkImageGenerator.cpp:110:12
    #7 0x220b961 in SkImage::MakeFromEncoded(sk_sp<SkData>, SkIRect const*) /usr/local/google/skia/out/msan/../../src/image/SkImage.cpp:138:39
    #8 0x2216949 in SkImageDeserializer::makeFromData(SkData*, SkIRect const*) /usr/local/google/skia/out/msan/../../src/image/SkImage.cpp:392:12
    #9 0x1d19d08 in SkReadBuffer::readImage() /usr/local/google/skia/out/msan/../../src/core/SkReadBuffer.cpp:312:48
    #10 0x2b460b8 in SkImageSource::CreateProc(SkReadBuffer&) /usr/local/google/skia/out/msan/../../src/effects/SkImageSource.cpp:66:33
    #11 0x21d27e6 in SkValidatingReadBuffer::readFlattenable(SkFlattenable::Type) /usr/local/google/skia/out/msan/../../src/core/SkValidatingReadBuffer.cpp:301:11
    #12 0x1686f74 in SkValidatingDeserializeFlattenable(void const*, unsigned long, SkFlattenable::Type) /usr/local/google/skia/out/msan/../../src/core/SkFlattenableSerialization.cpp:26:19
    #13 0x1687352 in SkValidatingDeserializeImageFilter(void const*, unsigned long) /usr/local/google/skia/out/msan/../../src/core/SkFlattenableSerialization.cpp:30:49
    #14 0xa61af9 in fuzz_filter_fuzz(sk_sp<SkData>) /usr/local/google/skia/out/msan/../../fuzz/fuzz.cpp:512:40
    #15 0xa500af in fuzz_file(char const*) /usr/local/google/skia/out/msan/../../fuzz/fuzz.cpp:131:13
    #16 0xa4ddb7 in main /usr/local/google/skia/out/msan/../../fuzz/fuzz.cpp:73:16
    #17 0x7f4412392f44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287
    #18 0x875323 in _start (/usr/local/google/skia/out/msan/fuzz+0x875323)

  Uninitialized value was stored to memory at
    #0 0x89f6d5 in __msan_memcpy.part.45 /tmp/tmpxvcw90/llvm/out/../projects/compiler-rt/lib/msan/msan_interceptors.cc:1463
    #1 0x20f61f8 in SkMemoryStream::read(void*, unsigned long) /usr/local/google/skia/out/msan/../../src/core/SkStream.cpp:318:9
    #2 0x20f6d25 in SkMemoryStream::peek(void*, unsigned long) const /usr/local/google/skia/out/msan/../../src/core/SkStream.cpp:329:44
    #3 0x287c202 in SkCodec::MakeFromStream(std::__1::unique_ptr<SkStream, std::__1::default_delete<SkStream> >, SkCodec::Result*, SkPngChunkReader*) /usr/local/google/skia/out/msan/../../src/codec/SkCodec.cpp:68:32
    #4 0x2885683 in SkCodec::MakeFromData(sk_sp<SkData>, SkPngChunkReader*) /usr/local/google/skia/out/msan/../../src/codec/SkCodec.cpp:126:12
    #5 0x7a6f5a3 in SkCodecImageGenerator::MakeFromEncodedCodec(sk_sp<SkData>) /usr/local/google/skia/out/msan/../../src/codec/SkCodecImageGenerator.cpp:12:18
    #6 0x297dad1 in SkImageGenerator::MakeFromEncodedImpl(sk_sp<SkData>) /usr/local/google/skia/out/msan/../../src/ports/SkImageGenerator_skia.cpp:12:12
    #7 0x1782125 in SkImageGenerator::MakeFromEncoded(sk_sp<SkData>) /usr/local/google/skia/out/msan/../../src/core/SkImageGenerator.cpp:110:12
    #8 0x220b961 in SkImage::MakeFromEncoded(sk_sp<SkData>, SkIRect const*) /usr/local/google/skia/out/msan/../../src/image/SkImage.cpp:138:39
    #9 0x2216949 in SkImageDeserializer::makeFromData(SkData*, SkIRect const*) /usr/local/google/skia/out/msan/../../src/image/SkImage.cpp:392:12
    #10 0x1d19d08 in SkReadBuffer::readImage() /usr/local/google/skia/out/msan/../../src/core/SkReadBuffer.cpp:312:48
    #11 0x2b460b8 in SkImageSource::CreateProc(SkReadBuffer&) /usr/local/google/skia/out/msan/../../src/effects/SkImageSource.cpp:66:33
    #12 0x21d27e6 in SkValidatingReadBuffer::readFlattenable(SkFlattenable::Type) /usr/local/google/skia/out/msan/../../src/core/SkValidatingReadBuffer.cpp:301:11
    #13 0x1686f74 in SkValidatingDeserializeFlattenable(void const*, unsigned long, SkFlattenable::Type) /usr/local/google/skia/out/msan/../../src/core/SkFlattenableSerialization.cpp:26:19
    #14 0x1687352 in SkValidatingDeserializeImageFilter(void const*, unsigned long) /usr/local/google/skia/out/msan/../../src/core/SkFlattenableSerialization.cpp:30:49
    #15 0xa61af9 in fuzz_filter_fuzz(sk_sp<SkData>) /usr/local/google/skia/out/msan/../../fuzz/fuzz.cpp:512:40
    #16 0xa500af in fuzz_file(char const*) /usr/local/google/skia/out/msan/../../fuzz/fuzz.cpp:131:13
    #17 0xa4ddb7 in main /usr/local/google/skia/out/msan/../../fuzz/fuzz.cpp:73:16
    #18 0x7f4412392f44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287

  Uninitialized value was created by a heap allocation
    #0 0x89f9dd in __interceptor_malloc /tmp/tmpxvcw90/llvm/out/../projects/compiler-rt/lib/msan/msan_interceptors.cc:942
    #1 0x297e29e in sk_malloc_flags(unsigned long, unsigned int) /usr/local/google/skia/out/msan/../../src/ports/SkMemory_malloc.cpp:73:15
    #2 0x297df16 in sk_malloc_throw(unsigned long) /usr/local/google/skia/out/msan/../../src/ports/SkMemory_malloc.cpp:59:12
    #3 0x177ac09 in SkReadBuffer::readByteArrayAsData() /usr/local/google/skia/out/msan/../../src/core/SkReadBuffer.h:171:24
    #4 0x1d19380 in SkReadBuffer::readImage() /usr/local/google/skia/out/msan/../../src/core/SkReadBuffer.cpp:301:33
    #5 0x2b460b8 in SkImageSource::CreateProc(SkReadBuffer&) /usr/local/google/skia/out/msan/../../src/effects/SkImageSource.cpp:66:33
    #6 0x21d27e6 in SkValidatingReadBuffer::readFlattenable(SkFlattenable::Type) /usr/local/google/skia/out/msan/../../src/core/SkValidatingReadBuffer.cpp:301:11
    #7 0x1686f74 in SkValidatingDeserializeFlattenable(void const*, unsigned long, SkFlattenable::Type) /usr/local/google/skia/out/msan/../../src/core/SkFlattenableSerialization.cpp:26:19
    #8 0x1687352 in SkValidatingDeserializeImageFilter(void const*, unsigned long) /usr/local/google/skia/out/msan/../../src/core/SkFlattenableSerialization.cpp:30:49
    #9 0xa61af9 in fuzz_filter_fuzz(sk_sp<SkData>) /usr/local/google/skia/out/msan/../../fuzz/fuzz.cpp:512:40
    #10 0xa500af in fuzz_file(char const*) /usr/local/google/skia/out/msan/../../fuzz/fuzz.cpp:131:13
    #11 0xa4ddb7 in main /usr/local/google/skia/out/msan/../../fuzz/fuzz.cpp:73:16
    #12 0x7f4412392f44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287

SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/local/google/skia/out/msan/../../third_party/externals/libpng/png.c:90:18 in png_sig_cmp
Exiting

There is a difference between this one and the one reported by clusterfuzz. The clusterfuzz report complains about the comparision in SkWbmpCodec::IsWbmp. My report complains about SkPngCodec::IsPng. When I step through gdb, I find that SkValidatingReadBuffer::readByteArray (called by SkReadBuffer::readByteArrayAsData) fails (in this case because the data is truncated - it expects 372 bytes, but only gets 368). This results in *not* writing into the passed in buffer, but readByteArrayAsData doesn't check the return value, and passes the uninitialized buffer to a new SkData, which we try to decode.

This definitely explains the uninitialized value, but we call IsPng (and some other checks) before IsWbmp. So it's weird that IsWbmp is the one that got caught by clusterfuzz, since the ones called first make the same comparison.

I have a fix in https://skia-review.googlesource.com/c/skia/+/52742

c8: Not sure how or why the reproduction steps were difficult to comprehend, since the process explained was quite similar to previously reported  crbug.com/756563 .

Also, I couldn't find the debug msan build to test and I haven't manually compiled it on my machine, so I can't say if the IsPng crashing location that you found is the same as the original report. 

BUT, we can re-test the Vulnerability in the more recent release, after the crrev fix you suggested is in place.

Thanks,
~ Kushal.

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/4cdbf6056de29e8c12c3b1b4c2c2fa286cf68049

commit 4cdbf6056de29e8c12c3b1b4c2c2fa286cf68049
Author: Leon Scroggins III <scroggo@google.com>
Date: Thu Sep 28 19:51:32 2017

Avoid uninitialized memory in readByteArrayAsData

Bug:  769134 

readByteArray can fail (due to not having enough available or due to the
wrong alignment). If it does, do not return an uninitialized block of
memory.

Further, drop the initial size check, which is covered by readByteArray.

Add a test.

Change-Id: Ia101697c5bb1ca3ae3df1795f37a74b2f602797d
Reviewed-on: https://skia-review.googlesource.com/52742
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>

[add] https://crrev.com/4cdbf6056de29e8c12c3b1b4c2c2fa286cf68049/resources/crbug769134.fil
[modify] https://crrev.com/4cdbf6056de29e8c12c3b1b4c2c2fa286cf68049/src/core/SkReadBuffer.h
[modify] https://crrev.com/4cdbf6056de29e8c12c3b1b4c2c2fa286cf68049/tests/ImageFilterTest.cpp

Please add appropriate OSs.

ClusterFuzz has detected this issue as fixed in range 505193:505210.

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

Job Type: linux_msan_filter_fuzz_stub
Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  read_header
  SkWbmpCodec::IsWbmp
  SkCodec::MakeFromStream
  
Sanitizer: memory (MSAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=linux_msan_filter_fuzz_stub&range=502343:502407
Fixed: https://clusterfuzz.com/revisions?job=linux_msan_filter_fuzz_stub&range=505193:505210

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

See https://github.com/google/clusterfuzz-tools 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 6149486165622784 is verified as fixed, so closing issue as verified.

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

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/c405b9d5e369c43d12b637518504dc51878d1c78

commit c405b9d5e369c43d12b637518504dc51878d1c78
Author: Leon Scroggins III <scroggo@google.com>
Date: Mon Oct 02 15:32:28 2017

Remove SkReadBuffer::validateAvailable

Follow on to 4cdbf6056de29e8c12c3b1b4c2c2fa286cf68049. readByteArray was
the only caller of this method, and no longer uses it. So remove it and
its only override.

Bug:  769134 
Change-Id: I0aaf97717baba1f0195162f3e644708bc101eba4
Reviewed-on: https://skia-review.googlesource.com/53920
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>

[modify] https://crrev.com/c405b9d5e369c43d12b637518504dc51878d1c78/src/core/SkValidatingReadBuffer.cpp
[modify] https://crrev.com/c405b9d5e369c43d12b637518504dc51878d1c78/src/core/SkValidatingReadBuffer.h
[modify] https://crrev.com/c405b9d5e369c43d12b637518504dc51878d1c78/src/core/SkReadBuffer.h

The panel declined to reward for this; but would be willing to take another look if a reliable path to exploitability could be demonstrated.

Hello awhalley,

Good Afternoon.

I am surprised by the difference in decision for this case.

For crbug.com/727678, crbug.com/726199,  crbug.com/683533 ,  crbug.com/574114  and  crbug.com/476647  , the panel readily rewarded the bounty to other researchers for the same kind of Vulnerability. 

BUT, for this report, no reward?? None of the other reports were asked for a 'reliable path to exploitability'. 

Also as per c#21 by awhalley for crbug.com/725127 (5 days ago), in the case of a fix being landed due to the report, a reward is rightly due...isn't it?

Could you please explain why a Vulnerability which is fixed promptly and which has been rewarded previously to other researchers, is being unfairly denied here?

Eagerly awaiting your response.

Thanks,
~ Kushal.

Hi Kushal,

Thanks for the query.

We only reward for security bugs we think are actually exploitable.  In the cases you cite, the panel could see how they could be exploited and thus rewarded.  In this case, they couldn't, I'm afraid.  But to give the benefit of the doubt, in such cases we ask the reporter if they could explain how this could be used in an exploit, in case we missed anything (rather than just change the bug type to no longer be a security bug, as we do in some cases where there's clearly no path to exploitation)

I know this must seem rather frustrating.

Cheers,

Andrew

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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