Heap-use-after-free in test_runner::WebWidgetTestClient::AnimateNow |
||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5136234300309504 Fuzzer: ochang_domfuzzer Job Type: linux_asan_content_shell_drt Platform Id: linux Crash Type: Heap-use-after-free READ 8 Crash Address: 0x617000049c00 Crash State: test_runner::WebWidgetTestClient::AnimateNow blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue blink::scheduler::TaskQueueManager::DoWork Sanitizer: address (ASAN) Recommended Security Severity: High Regressed: https://clusterfuzz.com/revisions?job=linux_asan_content_shell_drt&range=502225:502253 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5136234300309504 Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Nov 27 2017
,
Nov 27 2017
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
,
Nov 27 2017
,
Nov 27 2017
Add a couple of ppl to cc to help triage this issue.
,
Nov 28 2017
+alexclarke, who has worked on TaskQueueManager::ProcessTaskFromWorkQueue. If this bug is only in the test runner, we can remove the security labels. But if the test runner is tickling a bug in Blink, then we have a real security bug.
,
Nov 28 2017
This is weird - it looks like the web_widget pointer is dangling here: https://cs.chromium.org/chromium/src/content/shell/test_runner/web_widget_test_client.cc?rcl=b756e3109445ab3e80df6e7bab43a6227b3de04d&l=52 But if I trace back its construction, it looks to be a leaky lazy instance.. https://cs.chromium.org/chromium/src/content/test/layouttest_support.cc?rcl=30ff548ccb973752c09c345fc773ef8ab9d01ddf&l=85
,
Dec 7 2017
,
Dec 11 2017
lukasza: 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
,
Dec 11 2017
I haven't been able to reproduce locally, but I think this is a bug. The WebViewFrameWidget gets destroyed in RenderViewImpl::Close(), and then gets de-referenced in WebWidgetTestClient::AnimateNow. This is likely a race, since the WebViewImpl is also closed RenderViewImpl::Close(), and the task is posted with a weak ptr to the WebViewImpl. The WebViewImpl must be closed between posting the task and executing it, and there must be something holding a strong reference to the WebViewImpl. We probably need to track the closing of the RenderViewImpl and null the WebViewFrameWidget somewhere, similar to how we set it on RenderViewCreated. Either way, this shouldn't be a security issue, as it would be test-only.
,
Dec 22 2017
ClusterFuzz testcase 5136234300309504 is flaky and no longer crashes, so closing issue. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
,
Mar 30 2018
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 |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by ClusterFuzz
, Nov 26 2017Labels: Test-Predator-Auto-Components