Cherry-pick fix for CVE-2015-123740.0.2214-based

Clear RenderFrameImpl::frame_ pointer after deleting it.

Also avoid dereferencing it in OnMessageReceived after deletion.

BUG=461191
TEST=No more crashes in RenderFrameImpl::OnMessageReceived

Review URL: https://codereview.chromium.org/1007123003

Change-Id: I0f2dcd9e9e78e4255f37ddaa8d5b75b0852d9521
Reviewed-by: Michael Brüning <michael.bruning@theqtcompany.com>

1 files changed, 9 insertions, 1 deletions

diff --git a/chromium/content/renderer/render_frame_impl.cc b/chromium/content/renderer/render_frame_impl.cc
index b715060a9c7..861eda159b4 100644
--- a/chromium/content/renderer/render_frame_impl.cc
+++ b/chromium/content/renderer/render_frame_impl.cc
@@ -887,6 +887,11 @@ void RenderFrameImpl::DidHideExternalPopupMenu() {
 #endif
 
 bool RenderFrameImpl::OnMessageReceived(const IPC::Message& msg) {
+  // We may get here while detaching, when the WebFrame has been deleted.  Do
+  // not process any messages in this state.
+  if (!frame_)
+    return false;
+
   // TODO(kenrb): document() should not be null, but as a transitional step
   // we have RenderFrameProxy 'wrapping' a RenderFrameImpl, passing messages
   // to this method. This happens for a top-level remote frame, where a
@@ -1932,8 +1937,11 @@ void RenderFrameImpl::frameDetached(blink::WebFrame* frame) {
   if (is_subframe)
     frame->parent()->removeChild(frame);
 
-  // |frame| is invalid after here.
+  // |frame| is invalid after here.  Be sure to clear frame_ as well, since this
+  // object may not be deleted immediately and other methods may try to access
+  // it.
   frame->close();
+  frame_ = nullptr;
 
   if (is_subframe) {
     delete this;