Suspected CL could be
https://chromium.googlesource.com/skia.git/+/ffa4a9213b4e754adc210fa02a3c4b1ae8d3b6d0

Last updated by mtklein @ weeks ago , please have a look and reassign if needed.

Thank you.

Oddly, looks like new is returning null.  Building content_shell now to see if I can find out more.

When we get a regressed link like this (https://cluster-fuzz.appspot.com/revisions?job=linux_asan_filter_fuzz_stub_32bit&range=318772:318836) can we not trust it?  I don't see that suspected SkOnce CL there inside the CLs listed.

Oh boy, content shell isn't gonna help me here is it?  Looks like the fuzz case is an image filter.

As far as I can tell, here's the story:
  - The image filter is an SkMergeImageFilter with two inputs:
   1) an SkImageSource
   2) an SkColorFilterImageFilter wrapping an SkLumaColorFilter

The SkImageSource seems okay, but the SkColorFilterImageFilter has been fuzzed so it can't be decoded (the 'l' in the first "Filter" has been capitalized).

We create an SkImageSource, then trying to create the SkColorFiLterImageFilter fails, so we need to clean up that SkImageSource.  We do, and ultimately in it's destructor we hit a piece of code to preemptively purge this SkImageSource from the global SkImageFilterCache.  It happens it never made it into the cache, but it's harmless to purge a filter that's not present.

We can be very, very certain that the SkImageSource was never cached, because we create that global cache on demand, and this purge call is actually triggering the creation of the global cache.  Yes, a little silly, but again, generally harmless.  That's the operator() and Create() stuff you see at the bottom of the stack.

Now we get to CacheImpl(), really CacheImpl::CacheImpl(), it's constructor.  It's being called in a perfectly ordinary way, new CacheImpl(some_arg).  The crash is failing when sub-constructing fLookup, an SkTDynamicHash.  Oddly, it's failing when writing to 0x4 (presumably, fDeleted) not 0x0 (fCount)... maybe ARM doesn't trap when you write directly to 0x0?  Crash was running on ARM, right?

Near as I can tell, this all means that while calling new CacheImpl(), operator new returned null.  It allocated us a shiny null pointer to construct that CacheImpl into, and we crash because that's not a safe place to write to.

Skia never, ever null checks new, and I thought it wasn't even legal for new to return null.  Is this perhaps a quirk of the fuzzer setup that this is possible?

It doesn't look like there's anything going wrong with the SkOnce related aspects of this stack (or really, any of it) so I'm going to step back from owning this one.

 Issue 627804  has been merged into this issue.

 Issue 626980  has been merged into this issue.

This sounds a lot like  http://crbug.com/627387 , where Rob came to the conclusion that the fuzzer isn't compiled the way Chrome is, i.e., to crash on a null malloc(). Feel free to dedup if I'm wrong.

Excellent!  I completely agree this is the same problem.  Thanks!

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 has detected this issue as fixed in range 485950:486007.

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

Fuzzer: sugoi_filter_fuzzer
Job Type: linux_asan_filter_fuzz_stub_32bit
Platform Id: linux

Crash Type: UNKNOWN WRITE
Crash Address: 0x00000004
Crash State:
  SkImageFilterCache::Get
  SkImageFilter::~SkImageFilter
  SkImageSource::~SkImageSource
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_filter_fuzz_stub_32bit&range=390115:390221
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_filter_fuzz_stub_32bit&range=485950:486007

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


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

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