Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

This is a serious security regression. 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

Can't reproduce this locally. Dan was also having issues reproducing Clusterfuzz issues this week, perhaps that's widespread bug?

Tom, pretty sure your CL is the culprit: https://chromium-review.googlesource.com/1054696

So while destroying PDFiumEngine and destroying the pages array, we disable the caret of the current edit, which stops the timer to make it blink. Eventually, PDFiumFormFiller::Form_KillTimer() is run. formfill_timers_ has already been deleted since it's declared below pages_, and accessing it causes the undefined behavior.

I believe this will fix it:
https://chromium-review.googlesource.com/c/chromium/src/+/1062195

Since I couldn't repro locally to verify the fix and the CL is question may trigger other preexisting issues, we might prefer a revert to be safe.

Dan found it can be reproduced without the Clusterfuzz tool - build Chrome in debug, open the .html in the testcase, click on the tiny blue edit box, close the window. Verified my fix works.

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

commit 111ee675e63fe9ff1023fd33f8fd64a3ec0906af
Author: Henrique Nakashima <hnakashima@chromium.org>
Date: Wed May 16 20:23:29 2018

PDF: Destroy timers after pages.

When destroying the page we may need to cancel timers. Currently, the timers
will be free'd before the page. This CL changes the destruction order to free
the pages before freeing the timers.

Bug:  843493 
Change-Id: Ic96707bd1dc7510f65218679dc12cd44ba012db8
Reviewed-on: https://chromium-review.googlesource.com/1062195
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Henrique Nakashima <hnakashima@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559264}
[modify] https://crrev.com/111ee675e63fe9ff1023fd33f8fd64a3ec0906af/pdf/pdfium/pdfium_engine.h

ClusterFuzz has detected this issue as fixed in range 559240:559264.

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

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_ubsan_vptr_chrome
Platform Id: linux

Crash Type: UNKNOWN READ
Crash Address: 0xfffffffd53f533f9
Crash State:
  CPWL_Timer::KillPWLTimer
  CPWL_Caret::SetCaret
  CPWL_EditCtrl::SetCaret
  
Sanitizer: undefined (UBSAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_chrome&range=558411:558414
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_chrome&range=559240:559264

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

See https://github.com/google/clusterfuzz-tools 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 4732061961945088 is verified as fixed, so closing issue as verified.

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