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

blink::EndCompositingDisplayItem::appendToWebDisplayItemList passes an IntRect as one of its arguments. bratell, you landed https://crrev.com/2805203003 in the blame range for this, can you please investigate?

 Issue 709751  has been merged into this issue.

A bit hard to trigger any kind of visible effect from a 4 byte read outside a buffer so I don't know if I'm able to reproduce or not, but it seems unlikely that the IntRect conversion change could have made this happen. Likely it changed nothing, and if it did change something, it was the value of the IntRect, and I don't know how the value of an IntRect could cause read-out-of bounds in the compositor/paint code.

Is it possible to bisect further? I saw no obvious other candidates in the change list but it is a long change list.

I didn't see anything else that would evidently cause this.

+danakj: you recently changed the fragment where ClusterFuzz is detecting the bad read (https://codereview.chromium.org/2750683002). Can you help triage?

ClusterFuzz has detected this issue as fixed in range 463791:463842.

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

Fuzzer: inferno_twister
Job Type: linux_asan_chrome_v8_arm
Platform Id: linux

Crash Type: Heap-buffer-overflow READ 4
Crash Address: 0xceb9a82c
Crash State:
  cc::EndCompositingDisplayItem const& cc::DisplayItemList::CreateAndAppendPairedE
  cc_blink::WebDisplayItemListImpl::appendEndCompositingItem
  blink::EndCompositingDisplayItem::appendToWebDisplayItemList
  
Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=462610:462875
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=463791:463842

Reproducer Testcase: https://clusterfuzz.com/download/AMIfv97GXQ789c4zzMHUMC0lPhDuxmJ1N_pqZfJKHiT2iMOincFunxxsAl_hl5oJyVvmdqLrC3omMm0-_WebVHUDshU6o6JcLg5Jfq_MY09LE1msqozPKSp-hxpXfDKKn2dsJCaOOqvM3bseZGX_Bxv1I9COAaz3c5w45Fop5jBzdZpejQ2pVv_mCGaiKNDgbhwHvwwB3VPcaO_JHPXiJa7jyGB4DFIPYthpuxLRM_dk5B7suQNcLcw96AnHrVjUrc4ZUlFMecCDyGhhWOHG4G559TCG4cV-ahCnf5tHxJw1M6VwqA23KhS8dnFla2vLDnigcq3U4ca074CqUpktqJ7OlK1Cw8DYPIXU7ADt0cjzzujPRuL38gk?testcase_id=4533083400568832


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

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

That's the 2nd time this class has been blamed for bad memory accesses lately. Peeviously when this happened there was a double free bug going around and freeing other peoples memory..

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