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

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

Mike, possibly related to your changes around sk_memset?

No, I don't think so.  It may have changed what the stack looks like?  sk_memset32() would likely previously have been inlined into SkPixmap::erase().

I'm reaching on triage, non-obvious to me where the issue is in this stack.. to Matt for a look/ideas

Trying again..to Matt for real this time

I'm not seeing anything interesting here.  The web page tries to allocate a series of large images:
18850x65535
18850x65535
18850x65535
18850x65535
Until it crashes on OOM (for me locally).

I suspect this is a case of malloc overcommitting.  I am concerned that this is considered a "regression".  Does that mean that it was working before?

hcm@ can you tell from the report if there was a revision where this used to work?  Otherwise I think we should close as "won't fix".

Ran new tests and yes Clusterfuzz seems to think this is reproducible on latest builds, and worked prior to 1/23.  Still thinking this may be something upstack as I don't see changes on our side that could be making this happen, but could be a bad bisect.  

+Mike for any other ideas

msarett: 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

This looks to me like a classic case of malloc() overcommitting.  Notice that the crash address is on a page boundary.

I'm going to close this.  Heather, is there an existing bug (that we can reference here) that suggests that we find a way to stop filing bugs on malloc() overcommits?

I don't recall one, will look around and/or open a new issue.

ClusterFuzz has detected this issue as fixed in range 456626:457732.

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

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_asan_chrome_v8_arm
Platform Id: linux

Crash Type: Heap-buffer-overflow WRITE 16
Crash Address: 0xacc00000
Crash State:
  sk_memset32
  SkPixmap::erase
  SkBitmap::eraseColor
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=445725:445853
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=456626:457732

Reproducer Testcase: https://clusterfuzz.com/download/AMIfv94yZLbWAlXeJPYUk-n28hJgfQ1wTw3MntfCyh4abjz7aXB33DP21biVWOdmVyZjNgzcUKZioj-qW_2_vzAlcIn9GI_4b7N5h_TCwTsbEhw95mYmOqh_SzxmmiUE-m_6bdda06cCC_q6PxbH9H4SBJ7dFy5oGqXm8O5X6jj3EZL7KwDHWYmgENn0aYOZfWQt3GKtrLpccR6X9x1r3TgAGXm-rUkg82pCtB390IDNTJ6vSXFaOpeW1GN-cnQ8YCsHxjK-QXxhs-Hdch1v9htj4y1sIS-IMfwvW68cqpQX_UcQDQA7jikhDZsa8Pnp84y3lI_6JaO-9qCTCYaaVbWeyjpBHzshp_wR3UpCYwjPkm_0BCLzNv7zIkh7viov1ZLlgRpDuZWHOnXU6F0BW-L4Du-fVSC25g?testcase_id=5909045740568576


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.

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