mtklein: do you mind taking a look at this?

The problem is unlikely to be in memset32 itself, but I wouldn't expect drawRect() to ever draw out of bounds.

#0 0xd1731691 in avx::memset32(unsigned int*, unsigned int, int) third_party/skia/src/opts/SkUtils_opts.h:20:23
#1 0xdac51dc3 in sk_memset32 third_party/skia/src/core/SkUtils.h:24:5
#2 0xdac51dc3 in SkColorShader::ColorShaderContext::shadeSpan(int, int, unsigned int*, int) third_party/skia/src/shaders/SkColorShader.cpp:68
#3 0xdb2cc51c in SkARGB32_Shader_Blitter::blitRect(int, int, int, int) third_party/skia/src/core/SkBlitter_ARGB32.cpp:398:28
#4 0xdabc9631 in blitrect third_party/skia/src/core/SkScan.cpp:22:14
#5 0xdabc9631 in SkScan::FillIRect(SkIRect const&, SkRegion const*, SkBlitter*) third_party/skia/src/core/SkScan.cpp:50
#6 0xdabcae30 in FillRect third_party/skia/src/core/SkScan.cpp:68:5
#7 0xdabcae30 in SkScan::FillRect(SkRect const&, SkRasterClip const&, SkBlitter*) third_party/skia/src/core/SkScan.cpp:110
#8 0xdaa5c3dd in SkDraw::drawRect(SkRect const&, SkPaint const&, SkMatrix const*, SkRect const*) const third_party/skia/src/core/SkDraw.cpp:809:21
#9 0xdb2a9591 in drawRect third_party/skia/src/core/SkDraw.h:42:15
#10 0xdb2a9591 in SkBitmapDevice::drawRect(SkRect const&, SkPaint const&) third_party/skia/src/core/SkBitmapDevice.cpp:206
#11 0xda8fda7d in SkCanvas::onDrawRect(SkRect const&, SkPaint const&) third_party/skia/src/core/SkCanvas.cpp:2018:27
#12 0xda8f3eef in SkCanvas::drawRect(SkRect const&, SkPaint const&) third_party/skia/src/core/SkCanvas.cpp:1714:11
... cc above here ...

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

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

+awhalley@, could you ptal and make sure fix is landed to trunk asap as it is reported as M61 Beta blocker. Thank you.

What fix?

Putting the Mike's on CC and myself as owner temporarily to see the report and what could be causing this further up the stack...

Any chance one of the recent display scheduler changes may be causing this crash? Pulling in that team for a look...

Following the stack further we have:
...
#13 0xea6e0892 in cc::SoftwareRenderer::ClearCanvas(unsigned int) cc/output/software_renderer.cc:161:22
#14 0xea6e0b4e in ClearFramebuffer cc/output/software_renderer.cc:169:5
#15 0xea6e0b4e in cc::SoftwareRenderer::PrepareSurfaceForPass(cc::DirectRenderer::SurfaceInitializationMode, gfx::Rect const&) cc/output/software_renderer.cc:188
#16 0xea617c9e in cc::DirectRenderer::DrawRenderPass(cc::RenderPass const*) cc/output/direct_renderer.cc:555:3
#17 0xea615555 in cc::DirectRenderer::DrawRenderPassAndExecuteCopyRequests(cc::RenderPass*) cc/output/direct_renderer.cc:491:3
#18 0xea612dc8 in cc::DirectRenderer::DrawFrame(std::__1::vector<std::__1::unique_ptr<cc::RenderPass, std::__1::default_delete<cc::RenderPass> >, std::__1::allocator<std::__1::unique_ptr<cc::RenderPass, std::__1::default_delete<cc::RenderPass> > > >*, float, gfx::Size const&) cc/output/direct_renderer.cc:301:5
#19 0xdf034ed1 in cc::Display::DrawAndSwap() cc/surfaces/display.cc:312:16
#20 0xdf03f9c8 in cc::DisplayScheduler::DrawAndSwap() cc/surfaces/display_scheduler.cc:193:27
#21 0xdf03c34f in cc::DisplayScheduler::AttemptDrawAndSwap() cc/surfaces/display_scheduler.cc:405:14
#22 0xdf03a337 in cc::DisplayScheduler::OnBeginFrameDeadline() cc/surfaces/display_scheduler.cc:421:19
#23 0xdf0404f7 in cc::DisplayScheduler::OnBeginFrameDerivedImpl(cc::BeginFrameArgs const&) cc/surfaces/display_scheduler.cc:234:5
#24 0xde7969af in cc::BeginFrameObserverBase::OnBeginFrame(cc::BeginFrameArgs const&) cc/scheduler/begin_frame_source.cc:45:15
#25 0xde79d859 in cc::DelayBasedBeginFrameSource::OnTimerTick() cc/scheduler/begin_frame_source.cc:249:12
#26 0xde79eab2 in non-virtual thunk to cc::DelayBasedBeginFrameSource::OnTimerTick() cc/scheduler/begin_frame_source.cc:0
#27 0xde7a52fc in cc::DelayBasedTimeSource::OnTimerTick() cc/scheduler/delay_based_time_source.cc:76:14
...

I don't think this is caused by my chagne. My CL sets the BeginFrameSouce for
DisplayScheduler in its ctor instead of using a separate SetBeginFrameSource
method.

brianderson@: Could you take a look? 

May be this is patch which introduced the crash but not sure though
 - https://chromium.googlesource.com/chromium/src/+log/97ea635cc998b3d39de0c08695b8a8feb3aa974f/cc/output/software_renderer.cc

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

hi brianderson@ - mind taking a look at this or re-assigning it if there's somebody better placed to do so quickly?

M61 is close to branching, please expedite the fix.

FWIW, I don't think the DisplayScheduler changes are likely to be causing this - while they may change when exactly drawing happens, they shouldn't change how it's done.

Since brianderson@ isn't really around at the moment, let's give this to ericrk@ b/c of #12 - Eric, maybe you've got a clue or know who might?

A friendly reminder that M61 branch is coming soon on 07/20! Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix ASAP to trunk. This way we branch M61 from a high quality trunk. Thank you.

ClusterFuzz has detected this issue as fixed in range 485950:486007.

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

Fuzzer: bj_broddelwerk
Job Type: linux_asan_chrome_v8_arm
Platform Id: linux

Crash Type: UNKNOWN WRITE
Crash Address: 0x0000ccd0
Crash State:
  avx::memset32
  SkColorShader::ColorShaderContext::shadeSpan
  SkARGB32_Shader_Blitter::blitRect
  
Sanitizer: address (ASAN)

Recommended Security Severity: Critical

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=480776:480840
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=485950:486007

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


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 5663131287420928 is verified as fixed, so closing issue.

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

The fixed range includes two skia rolls - any idea which change might have addressed this?

One roll was a revert to eliminate an issue with one CL, then a fresh roll.  I don't see any changes that could have affected the code in this stack and still believe this was coming from somewhere upstack vs Skia.  

I did look at the range for interesting changes to scheduling/rendering/etc above Skia, but do not see anything obvious.

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