==1==ERROR: AddressSanitizer: SEGV on unknown address 0x7f2231598000 (pc 0x7f23fa7fcc20 bp 0x7f223a849b30 sp 0x7f223a849aa0 T4)
SCARINESS: 10 (signal)
    #0 0x7f23fa7fcc1f in sk_memset32 third_party/skia/src/core/SkUtils.h:31:19
    #1 0x7f23fa7fcc1f in SkPixmap::erase(unsigned int, SkIRect const&) const third_party/skia/src/core/SkPixmap.cpp:204
    #2 0x7f23fa6e7790 in SkBitmap::erase(unsigned int, SkIRect const&) const third_party/skia/src/core/SkBitmap.cpp:718:25
    #3 0x7f23fa6e7bf2 in SkBitmap::eraseColor(unsigned int) const third_party/skia/src/core/SkBitmap.cpp:724:11
    #4 0x7f23fcaf94fb in eraseARGB third_party/skia/include/core/SkBitmap.h:510:15

bsalomon, could you please take a look at this Skia crash? Thanks!

Looks more up reed@'s alley than mine.

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

The BMP reports dimension that require an allocation of approx 500M. I suspect that malloc over-committed for this, as all of the crash addresses area always on a 4K boundary.

Agreed. This image reports a size of 63,501 x 8,128 (which sounds a lot like  issue 557799 , where we had a BMP with dimensions of 64,000 x 8,193)

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

Fuzzer: inferno_sampler
Job Type: linux_asan_chrome_media
Platform Id: linux

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

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_media&range=357589:358520

Minimized Testcase (3.37 Kb): https://cluster-fuzz.appspot.com/download/AMIfv97oBfoI_n8ePUl97in_R3doxaaEm7AwxibAkc4hDSYeRy9etTsVx1EV4R3EBXhLZlGq-qYDa2o0iIQd6sGzGSdoTPymNLzGuUKEeGnUP0Jsxxn4W5JvMYYZEIaXIbvzaqBM2AE24ukWzCdofYq4hkhATw_66Q?testcase_id=6561042746572800

Filer: ochang

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

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

Unassigning.

This appears to be bad memory returned by malloc. The request (from the crazy bmp file) is for almost 2gig. When skia is asked to erase it, we try to write to the start of a page and crash.

Not sure how skia can address this, since memory allocations are external to it.

Is this related to  crbug.com/627387  ?

Does anyone know if there are malloc options to not over-commit?

If it's related to  crbug.com/627387 , it's not so obviously related as the others.  They're returning NULL for a failed malloc because there was no virtual memory left to allocate, where this would be failing at some later step down the line, possibly where we've got a perfectly fine block of virtual memory that later can't be backed by real memory.  Have we already ruled out that we're just writing to a bad address (overflow, bad pointer, etc)?

Looks like the things to try to dodge overcommit are:
   - call mlock(ptr, size) after malloc
   - allocate using mmap with MAP_LOCKED or MAP_POPULATE

In my 5 minutes of reading, the difference between locked and populate comes down to swap. Locked == force residence in memory until I call munlock(), while MAP_POPULATE just forces it now, not preventing swap out later.

This bug has no owner currently. As mtklein said, have steps been taken to make sure that skia isn't just writing to a bad address? Is skia using tcmalloc() or doe sit do its own memory allocation?

When linked into Chrome, Skia uses the routines in skia/ext/SkMemory_new_handler.cpp to allocate memory.  Generally we use sk_malloc_throw(), but in a few places where we expect to make large allocations, we'll get into sk_malloc_nothrow().

Is there something the SkMemory_new_handler.cpp could do to limit requests to a reasonable image size? 2G seems like an excessively large request to honor.

Sure, intentionally crash?

Yes, or alternatively, if this is indeed an over-commit by malloc, as reed suggests, this is probably an OOM and can be WontFix-ed. 

Oh yeah, most definitely an OOM.

I thought perhaps we were trying to do something fancy about _that_.

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