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

thestig: This looks like a pdfium bug, can you please take a look? Thanks.

This is pretty far away from PDF code. +input folks.

The regression range includes sahel@ enabling scroll latching for test configurations. If this only repros with scroll latching enabled then it isn't a release blocker.

MouseWheelPhaseHandler::SendSyntheticWheelEventWithPhaseEnded is only called when wheel scroll latching is enabled, so the change in test configuration has caused the crash.

Investigating more to see why the crash happens when latching is enabled..

This may have only been reported on Linux, but it almost certainly affects other platforms too; anywhere that we are using wheel latching.

That is often the case with Cluster-Fuzz reports. I believe UBSAN only runs on Linux, and we usually add the other platforms after the bug cause is clear.

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

commit 8e0187e5048b9b2795ff4b764f00f8b8b1864334
Author: Sahel Sharify <sahel@chromium.org>
Date: Thu Sep 21 04:41:49 2017

Wheel target resets when it is equal to the destroyed view.

When wheel scroll latching is enabled, wheel events are routed to the
same target during a scrolling sequence. On devices that don't have
phase info (currently every device other than mac) the wheel end event
is generated and sent based on a timer timeout 100ms after the last
wheel event. It's possible that during the 100ms the wheel target gets
destroyed and trying to send the wheel end event to the destroyed target
causes a crash (Produced by the clusterfuzz testcase in the bug).

This change resets the wheel target when it's equal to the view which is
being destroyed. The following test fails without applying this change.

Bug:  764248 
Test: SitePerProcessMouseWheelBrowserTest.InputEventRouterWheelTargetTest
Change-Id: Iadd5158db5a41af751c4a52a58a2ebfb571d826a
Reviewed-on: https://chromium-review.googlesource.com/668667
Commit-Queue: Sahel Sharifymoghaddam <sahel@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503353}
[modify] https://crrev.com/8e0187e5048b9b2795ff4b764f00f8b8b1864334/content/browser/renderer_host/render_widget_host_input_event_router.cc
[modify] https://crrev.com/8e0187e5048b9b2795ff4b764f00f8b8b1864334/content/browser/renderer_host/render_widget_host_input_event_router.h
[modify] https://crrev.com/8e0187e5048b9b2795ff4b764f00f8b8b1864334/content/browser/site_per_process_browsertest.cc

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