Author: alexmos
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src//+/c2a8cec37a56e92d29d91b936734cd1e5ee28734
Time: Mon May 23 22:19:53 2016
File web_contents_impl.cc is changed in this cl (and is part of stack frame #4, "content::WebContentsImpl::Init"; frame #5, "content::WebContentsImpl::CreateWithOpener"; frame #6, "content::WebContents::Create")
Minimum distance from crash line to modified line: 46. (file: web_contents_impl.cc, crashed on: 1502, modified: 1456).

Suspected Project: chromium
Suspected Component: Internals>Sandbox>SiteIsolation

I couldn't get the testcase to repro the uaf on my machine, so it's hard to see exactly what's going on.  When I run the testcase, the test app opens in a new window and then crashes, but there's no uaf report.  However, I do see "Terminating renderer because of malformed extension message" in the output, which also appears in the report's output.  That message was added in lazyboy@'s https://codereview.chromium.org/1880933002, which is in the regression range, and which seems like it also might have tinkered with various object lifetimes, and touched UIThreadExtensionFunction::SetRenderFrameHost and other codepaths that might be involved here (see below). lazyboy@: mind taking a look if that CL could be the cause?

Here's what's happening from inspecting the call stacks:
1. We open a new app window and as part of that, we create a new WebContents, and main frame RFHM and RFH.
2. Main frame RFH is freed as part of WebContents being destroyed via ~AppWindowContentsImpl.
3. That RFH is reused by extensions::MediaGalleriesGetMediaFileSystemsFunction::ReturnGalleries.  The RFH seems to be obtained from UIThreadExtensionFunction::render_frame_host_, which was supposed to be set to null by RenderFrameDeleted (which should've been called when we destroyed the RFH in step 2).

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

@3, yea, I missed clearing render_frame_host_ to nullptr because of a flawed assumption:
https://code.google.com/p/chromium/codesearch#chromium/src/extensions/browser/extension_function.cc&l=457

Going to fix once I can look at the repro case.

Okay, I've looked into the repro, it seems sockets.connect is throwing off the app too early with negative port id. That results in the renderer kill. If I turn it off, I can hit (very infrequently though) the UAF of render_frame_host_

I'm going to fix by properly clearing render_frame_host_ mentioned above.

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

commit fd6715d5469aaa2fa05bc3ab316767d6ea84867e
Author: lazyboy <lazyboy@chromium.org>
Date: Thu Jun 02 16:08:31 2016

Clear UIThreadExtensionFunction::render_frame_host_ when RFH is gone.

This regressed in my CL r395494 where I mistakenly put a short circuit
in SetRenderFrameHost. SetRenderFrameHost is called with nullptr RFH
when WebContentsObserver::RenderFrameDeleted() happens (for
non service worker case).

BUG= 616119 
Test=See clusterfuzz repro, it infrequently reproduces though. But
I was able to verify with this CL that the crash shouldn't happen.

Review-Url: https://codereview.chromium.org/2034543002
Cr-Commit-Position: refs/heads/master@{#397432}

[modify] https://crrev.com/fd6715d5469aaa2fa05bc3ab316767d6ea84867e/extensions/browser/extension_function.cc
[modify] https://crrev.com/fd6715d5469aaa2fa05bc3ab316767d6ea84867e/extensions/browser/extension_function.h
[modify] https://crrev.com/fd6715d5469aaa2fa05bc3ab316767d6ea84867e/extensions/browser/extension_function_dispatcher.cc

ClusterFuzz has detected this issue as fixed in range 397421:397444.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5610111062245376

Fuzzer: meacer_extension_apis
Job Type: linux_asan_chrome_mp
Platform Id: linux

Crash Type: Heap-use-after-free READ 8
Crash Address: 0x618000055c80
Crash State:
  extensions::ConstructFileSystemList
  extensions::MediaGalleriesGetMediaFileSystemsFunction::ReturnGalleries
  ExtensionGalleriesHost::GetMediaFileSystemsForAttachedDevices
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_mp&range=395419:395561
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_mp&range=397421:397444

Minimized Testcase (6.61 Kb): https://cluster-fuzz.appspot.com/download/AMIfv94A8FyQmXmilQAwLl_uPAZ_KBRr-DfBxkN4ar-3Y-w87Nl7lT4jXFkfaQ-my7uJ1a1KfECSkdJ6S2INzKySPHVj2_7mAreED51RKDm2Na6xWUDMJ7c2n2HaETKW_kD_bZC8iLQkjehdhOTlxEDthoh4DcB2Kg

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.

Fix is already in M53, removing ReleaseBlock-Beta.

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

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

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