Ensure that in-process plugins can't destroy themselves by closing a URLLoader

content/renderer/pepper/pepper_in_process_router.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/renderer/pepper/pepper_in_process_router.h"
 
 #include "base/bind.h"
 #include "base/message_loop/message_loop.h"
 #include "content/public/renderer/render_thread.h"
 #include "content/renderer/pepper/renderer_ppapi_host_impl.h"
@@ skipping 85 matching lines @@
   // If the resource doesn't exist, it may have been destroyed so just ignore
   // the message.
   if (resource)
     resource->OnReplyReceived(reply_params, nested_msg);
   return true;
 }
 
 bool PepperInProcessRouter::SendToHost(IPC::Message* msg) {
   scoped_ptr<IPC::Message> message(msg);
 
+  // Unpack the message so we can peek at its nested type.
+  uint32 call_type = 0;
+  if (message->type() == PpapiHostMsg_ResourceCall::ID) {
+    ppapi::proxy::ResourceMessageCallParams call_params;
+    IPC::Message nested_msg;
+    if (!UnpackMessage<PpapiHostMsg_ResourceCall>(*msg, &call_params,
+                                                  &nested_msg)) {
+      NOTREACHED();
+      return false;
+    }
+    call_type = nested_msg.type();
+    // Repack the message.
+    message.reset(new PpapiHostMsg_ResourceCall(call_params, nested_msg));
+  }
+
   if (!message->is_sync()) {
-    // If this is a resource destroyed message, post a task to dispatch it.
-    // Dispatching it synchronously can cause the host to re-enter the proxy
-    // code while we're still in the resource destructor, leading to a crash.
-    // http://crbug.com/276368.
-    // This won't cause message reordering problems because the resource
-    // destroyed message is always the last one sent for a resource.
     if (message->type() == PpapiHostMsg_ResourceDestroyed::ID) {
+      // If this is a resource destroyed message, post a task to dispatch it.
+      // Dispatching it synchronously can cause the host to re-enter the proxy
+      // code while we're still in the resource destructor, leading to a crash.
+      // http://crbug.com/276368.
+      // This won't cause message reordering problems because the resource
+      // destroyed message is always the last one sent for a resource.
       base::MessageLoop::current()->PostTask(
           FROM_HERE,
           base::Bind(&PepperInProcessRouter::DispatchHostMsg,
+                     weak_factory_.GetWeakPtr(),
+                     base::Owned(message.release())));
+      return true;
+    } else if (call_type == PpapiHostMsg_URLLoader_Close::ID) {
+      // If this is a PpapiHostMsg_URLLoader_Close, it could trigger the
+      // destruction of the instance (crbug.com/372548) so post a task to
+      // dispatch it as well. Because PpapiHostMsg_ResourceDestroyed messages
+      // are also posted above, ordering with respect to those messages will
+      // still be correct. Ordering with respect to other messages should not
+      // be important.
+      base::MessageLoop::current()->PostTask(
+          FROM_HERE,
+          base::Bind(&PepperInProcessRouter::DispatchHostMsg,
                      weak_factory_.GetWeakPtr(),
                      base::Owned(message.release())));
       return true;
     } else {
       bool result = host_impl_->GetPpapiHost()->OnMessageReceived(*message);
       DCHECK(result) << "The message was not handled by the host.";
       return true;
     }
   }
 
@@ skipping 36 matching lines @@
 void PepperInProcessRouter::DispatchPluginMsg(IPC::Message* msg) {
   bool handled = OnPluginMsgReceived(*msg);
   DCHECK(handled);
 }
 
 bool PepperInProcessRouter::SendToBrowser(IPC::Message* msg) {
   return RenderThread::Get()->Send(msg);
 }
 
 }  // namespace content