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

Possibly https://skia.googlesource.com/skia.git/+/4447b64a88ea141161fca772c2fec28b6141bbc3

Here are the parameters the SkPixmap::erase call is seeing:

SkPixmap::erase w: 1099 h: 3819 inArea: 0 0 1099 3819 rowBytes: 4396

+more Skia folks for triage. This bug has been sitting around for a little while now

overcommit by malloc?

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

Right, definitely no bug in sk_memset32.  But, UNKNOWN WRITE doesn't sound like overcommit.  I don't think Windows does overcommit.  

Here's the part of the stack that looks interesting to me.

SkPictureImageGenerator::onGetPixels [0x56766551+321] (third_party\skia\src\core\SkPictureImageGenerator.cpp:97)
SkImageGenerator::getPixels [0x5675FB74+180] (third_party\skia\src\core\SkImageGenerator.cpp:54)
SkImageCacherator::directGeneratePixels [0x56486440+256] (third_party\skia\src\core\SkImageCacherator.cpp:175)
SkImage_Generator::onReadPixels [0x56760800+256] (third_party\skia\src\image\SkImage_Generator.cpp:58)
cc::SoftwareImageDecodeCache::GetOriginalImageDecode [0x5728D4F8+2184] (cc\tiles\software_image_decode_cache.cc:584)
cc::SoftwareImageDecodeCache::DecodeImageInternal [0x5728A3C0+1856] (cc\tiles\software_image_decode_cache.cc:443)
cc::SoftwareImageDecodeCache::GetDecodedImageForDrawInternal [0x57291ABF+3471] (cc\tiles\software_image_decode_cache.cc:520)
cc::SoftwareImageDecodeCache::GetDecodedImageForDraw [0x5729080B+987] (cc\tiles\software_image_decode_cache.cc:463)
cc::`anonymous namespace::ScopedDecodedImageLock::ScopedDecodedImageLock [0x57377B37+887] (cc\playback\image_hijack_canvas.cc:34)
cc::`anonymous namespace::ScopedImagePaint::TryCreate [0x573790B4+756] (cc\playback\image_hijack_canvas.cc:92)
cc::ImageHijackCanvas::onDrawRRect [0x5737A762+194] (cc\playback\image_hijack_canvas.cc:257)

This appears to be a bug further up the call chain. From GetOriginalImageDecode on down the pixels Chrome hands to us are pretty much piped straight down to the point where we're clearing them. I don't really know anything about the semantics of DiscardableMemoryAllocator on Windows (which is allocating the pixels in GetOriginalImageDecode).

reed - Can you suggest another owner?  This has been unaddressed for 4 weeks. Thanks.

The repro case doesn't seem to go down the image decode path for me at all (since the svg image isn't "lazy", at least on my machine?). +reveman for the discardable allocation. The software cache does an alloc from the discardable memory and just passes that info to readPixels. Is it possible that we're getting some invalid memory from discardable?

It should always be valid unless someone has unlocking the memory. Could be bugs of course but I'd expect it to happen more frequently with different stack traces in that case as skia is not the only place we write to discardable memory.

This is where we allocate and immediately read: https://cs.chromium.org/chromium/src/cc/tiles/software_image_decode_cache.cc?l=585

It's a local object so nobody else would have access... If this path was broken here, then I'd also expect to see a lot more failures.

Does anyone actually have a local repro? I've tried the sample testcase locally and it behaves as I would expect (ie no crash)

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

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

Fuzzer: inferno_layout_test_unmodified
Job Type: windows_asan_chrome_no_sandbox
Platform Id: windows

Crash Type: UNKNOWN WRITE
Crash Address: 0xa685f000
Crash State:
  sk_memset32
  SkPixmap::erase
  SkBitmap::eraseColor
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_chrome_no_sandbox&range=446229:446231
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_chrome_no_sandbox&range=456626:457730

Reproducer Testcase: https://clusterfuzz.com/download/AMIfv94h09MShMj7_W6S6BHI_6JlZuHnzEiUYWUGNE88aePRC6FzN8b5supIunI1Hhbi5GtqEszyFkiBcGZtW4TC3P0LvTGt-Ql7v0TGwCuXoaTwRJQUxheUvm3CVLpqZykf93Q-A-FN0VpEtWseWptC0xTLvxo5Jk0MMb4-19El4El7BlrK3tE2GDWH8k1CDgDiSE32uYImSkm7BHPGB0GDuxm3jFlSwB5xVyo2IX7tvB6s9nZh_nvjshhX1H1v-CPOlckzAItRV4iCkd9T9HJH2YnvP5evkfgDr2bMNlA33D-dp38vZcOHJXFuchtCiMUMluOpgC8fevNSRFRQDFEHnvbR9doH4sY09PaBLhlA7YBXmU9E4So?testcase_id=5131337490235392


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.

ClusterFuzz testcase 5131337490235392 is verified as fixed, so closing issue.

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

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

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

I don't think we have anything to merge here, a miracle happened.

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