reed: could you please help triage this? Thanks!

reed: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

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

Fuzzer: inferno_sampler
Job Type: linux_asan_chrome_media
Platform Id: linux

Crash Type: UNKNOWN
Crash Address: 0x7f9eaa508000
Crash State:
  SkPixmap::erase
  SkBitmap::erase
  SkBitmap::eraseColor
  
Recommended Security Severity: Medium


Minimized Testcase (2.51 Kb): https://cluster-fuzz.appspot.com/download/AMIfv94cwAaANEfTHOlh_aSZJ5IbAhQvcBQ_Z81Ea115Zfe6tTnRxZuiehjPvzPgcp_8Tk8XXTtW4JO7_sMRr3gJDN_tWcmhV_b04D-ouJKvi2WMLU4SjSMBnKcoQa8k343K_dQq7J4-MUsEUYsLHC8b9U3NLDjzIw?testcase_id=5046374217547776

Issue manually filed by: inferno

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

Looks like caused by 

Author: mtklein
Project: chromium-skia
Changelist: https://chromium.googlesource.com/skia.git/+/3bc2624a4b89c49efd65f5e548ac5f2dd9351431
Time: Wed Feb 17 22:21:28 2016
The CL last changed line 31 of file SkUtils.h, which is stack frame 0.

Mike, can you please take a look.

Hmm, looks like we are trying to decode a 8240x64554 = 1.98GB .jpeg.

I think it's unlikely to be a problem anywhere on the stack between #0 and at least #5, where we attempt to clear a buffer to transparent black.  If there were bugs there, all Chromes would be crashing all the time.

My guess is we've gone wrong somewhere in the #11-#19 range.  If we're clearing a bad buffer, I suspect the allocator or caching.

Mike, is there somewhere we or Blink should be cutting this off for being larger than safe that we may have missed?

Other folks, any idea what an overcommit failure looks like in ASAN?  This might just be OOM.

Given the address is on a page boundary 0x7fa4935b1000 I also suspect overcommit.

Cuttoff for too-large an allocation is tricky/unreliable, since we have multiple threads going on that can be allocating large things.

Kostya, can you please answer c#9. 

1.98GB is unlikely to cause asan to fail with overcommit. 
although if it were an overcommit it would probably look like this.

The size is suspiciously close to 2G, and the sizes are 'int'. 
Is it possible that there is an int overflow somewhere here? 

(started building new chrome to reproduce) 

I couldn't reproduce this with a local build, 
but I did reproduce an overcommit asan failure and it looks different. 
(When overcommit happens, the process will die silently, it won't be able to produce such a spectacular error report)

reed: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Both crashes are marked as non reproducible.

reed@, could you please close the issue if there is nothing to do?

kcc/reed: Can we close this as wontfix or is there pending work to do? Thanks!

I'm going to guess this is the same as https://bugs.chromium.org/p/chromium/issues/detail?id=598724#c44. Either way, the CF crash is no longer reproducible. 

ASan seems to output "SEGV" even for SIGBUS crashes (https://cs.chromium.org/chromium/src/third_party/llvm/compiler-rt/lib/asan/asan_posix.cc?q=asan_posix.cc&sq=package:chromium&dr=C&l=36), which is probably what's happening here.

kcc, do you think we could change ASAn to output BUS instead of SEGV in this case?

Sure, we can, but I'd prefer not to, unless we see this as a big problem. 
Do we?

It's usually not a big problem, but we occasionally see this for skia and have no way of telling. 

What's the reason for preferring to keep SEGV?

1. don't want to change the behavior that works
2. I've seen cases when a bug causes SIGBUS on one platform and something else on another platform. 

Sure, in that case could we at least get the real signal number in the output somewhere?

that would also be a trivial change, but it may break someone's report parsers. 

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