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

wangxianzhu: Would you mind taking a look?
 Might be related to https://chromium.googlesource.com/chromium/src/+/a16e62c523aac46945d3782fea8bda79247879d9

See regression range; this was clearly a regression on trunk, which is M60.  mbarbella@ is aware of the clusterfuzz@ bug-filing issue here and is working on a fix.  Retargeting to M61 in the meantime.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/61479a32e7d392656f32688a4dc733b3e19a87cc

commit 61479a32e7d392656f32688a4dc733b3e19a87cc
Author: Xianzhu Wang <wangxianzhu@chromium.org>
Date: Fri Jun 09 04:24:21 2017

SetNeedsRepaint when a layer changes self painting status

The problem was that when a layer changed self painting status, the
compositing container chain might also change. If some descendant
was removed from the layer later, we would mark only the new
compositing container chain for repaint. If there was some stacking
context layer in the old compositing container chain not in the new
compositing container chain had generated cached subsequence, the
subsequence would miss invalidation.

Now call SetNeedsRepaint before changing self painting status, and
mark new compositing container chain for repaint after changing self
painting status.

BUG= 729383 

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I15c407be90e563071476dfe867bbb992a65fbedf
Reviewed-on: https://chromium-review.googlesource.com/528019
Reviewed-by: Chris harrelson <chrishtr@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#478198}
[modify] https://crrev.com/61479a32e7d392656f32688a4dc733b3e19a87cc/third_party/WebKit/Source/core/paint/PaintLayer.cpp
[modify] https://crrev.com/61479a32e7d392656f32688a4dc733b3e19a87cc/third_party/WebKit/Source/core/paint/PaintLayerTest.cpp

The issue also affects M-60. The regression range was not accurate.

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

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

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d51af084b5e58c84e490538ba7011c1da6d005c8

commit d51af084b5e58c84e490538ba7011c1da6d005c8
Author: Xianzhu Wang <wangxianzhu@chromium.org>
Date: Fri Jun 09 15:46:07 2017

SetNeedsRepaint when a layer changes self painting status

The problem was that when a layer changed self painting status, the
compositing container chain might also change. If some descendant
was removed from the layer later, we would mark only the new
compositing container chain for repaint. If there was some stacking
context layer in the old compositing container chain not in the new
compositing container chain had generated cached subsequence, the
subsequence would miss invalidation.

Now call SetNeedsRepaint before changing self painting status, and
mark new compositing container chain for repaint after changing self
painting status.

BUG= 729383 
TBR=wangxianzhu@chromium.org

(cherry picked from commit 61479a32e7d392656f32688a4dc733b3e19a87cc)

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I15c407be90e563071476dfe867bbb992a65fbedf
Reviewed-on: https://chromium-review.googlesource.com/528019
Reviewed-by: Chris harrelson <chrishtr@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#478198}
Reviewed-on: https://chromium-review.googlesource.com/529266
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#281}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/d51af084b5e58c84e490538ba7011c1da6d005c8/third_party/WebKit/Source/core/paint/PaintLayer.cpp
[modify] https://crrev.com/d51af084b5e58c84e490538ba7011c1da6d005c8/third_party/WebKit/Source/core/paint/PaintLayerTest.cpp

ClusterFuzz has detected this issue as fixed in range 478152:478270.

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

Fuzzer: marty_html_twiddler
Job Type: windows_asan_chrome_no_sandbox
Platform Id: windows

Crash Type: Heap-use-after-free WRITE 4
Crash Address: 0x08265588
Crash State:
  blink::PaintController::CommitNewDisplayItems
  blink::GraphicsLayer::Paint
  blink::LocalFrameView::PaintGraphicsLayerRecursively
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_chrome_no_sandbox&range=475250:475393
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_chrome_no_sandbox&range=478152:478270

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


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

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

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