Bug 39323 – Repro crash with many Google image search results

• Status: RESOLVED
• Resolution: FIXED
• Component: Page Loading

[Brady Eidson]

Repro crash with many Google image search results

Steps to reproduce:
1. Click the following G.I.S. link:

http://www.google.com/imgres?imgurl=http://www.jetsetreport.com/admin2/photos/1_2.jpg&imgrefurl=http://www.jetsetreport.com/nightlife.php%3FarticleId%3D273&h=400&w=400&sz=142&tbnid=ktJvcGmr5X9wdM:&tbnh=124&tbnw=124&prev=/images%3Fq%3Dpacha%2Bmarrakech&usg=__10-y4cSC3cRK05lXmqXoBIrT8lo=&ei=ksLyS7mNB4vysQPtzoyYDA&sa=X&oi=image_result&resnum=8&ct=image&ved=0CDAQ9QEwBw

2. Crash!

>  1 com.apple.WebKit               0x7fffa6e2ce53 WebFrameLoaderClient::redirectDataToPlugin(WebCore::Widget*) + 0x37
   2 com.apple.WebCore              0x7fffacf3d46b WebCore::PluginTokenizer::writeRawData(char const*, int) + 0x7b
   3 com.apple.WebCore              0x7fffacbee2a2 WebCore::FrameLoader::write(char const*, int, bool) + 0x11c
   4 com.apple.WebCore              0x7fffacc266b1 WebCore::FrameLoader::addData(char const*, int) + 0xb
   5 com.apple.WebKit               0x7fffa6de59d7 -[WebFrame(WebInternal) _addData:] + 0xa7
   6 com.apple.WebKit               0x7fffa6de5000 -[WebFrame(WebInternal) _receivedData:textEncodingName:] + 0x100
   7 com.apple.WebKit               0x7fffa6de4d41 -[WebHTMLRepresentation receivedData:withDataSource:] + 0x91
   8 com.apple.WebKit               0x7fffa6de4c10 -[WebDataSource(WebInternal) _receivedData:] + 0x50
   9 com.apple.WebKit               0x7fffa6de4b97 WebFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, char const*, int) + 0x69
  10 com.apple.WebCore              0x7fffacc1ee60 WebCore::FrameLoader::committedLoad(WebCore::DocumentLoader*, char const*, int) + 0x44
  11 com.apple.WebCore              0x7fffacc1ca30 WebCore::DocumentLoader::receivedData(char const*, int) + 0x90
  12 com.apple.WebCore              0x7fffacc1c999 WebCore::FrameLoader::receivedData(char const*, int) + 0x25
  13 com.apple.WebCore              0x7fffacc1c879 WebCore::MainResourceLoader::addData(char const*, int, bool) + 0x37
  14 com.apple.WebCore              0x7fffacc1c7d6 WebCore::ResourceLoader::didReceiveData(char const*, int, long long, bool) + 0x38
  15 com.apple.WebCore              0x7fffacc1c740 WebCore::MainResourceLoader::didReceiveData(char const*, int, long long, bool) + 0x262
  16 com.apple.WebCore              0x7fffacc1c4db WebCore::ResourceLoader::didReceiveData(WebCore::ResourceHandle*, char const*, int, int) + 0x1b
  17 com.apple.WebCore              0x7fffacc1c4b1 -[WebCoreResourceHandleAsDelegate connection:didReceiveData:lengthReceived:] + 0x91
...

The Widget is null.  The PluginDocument has an embed element, that has a RenderWidget, but it didn't actually create a widget.

The reason why is due to sandboxing, which g.i.s. uses when iframing the source page for an image result.

In FrameLoader::requestObject():
...
    bool useFallback;
    if (shouldUsePlugin(completedURL, mimeType, renderer->hasFallbackContent(), useFallback)) {
        Settings* settings = m_frame->settings();
        if ((!allowPlugins(AboutToInstantiatePlugin)
             // Application plugins are plugins implemented by the user agent, for example Qt plugins,
             // as opposed to third-party code such as flash. The user agent decides whether or not they are
             // permitted, rather than WebKit.
             && !MIMETypeRegistry::isApplicationPluginMIMEType(mimeType))
            || (!settings->isJavaEnabled() && MIMETypeRegistry::isJavaAppletMIMEType(mimeType)))
            return false;
        if (isDocumentSandboxed(m_frame, SandboxPlugins))
            return false;
...

Later, the plugin data is being fed to this nonexistent Widget.

In radar as <rdar://problem/7685669>

[Brady Eidson]

This will only happen on sites that use an <iframe> but set the src to a plugin.

<iframe src="foo.swf">, for example.

I have a patch coming up that will replace the plugin document with a sink document that just throws the data away and renders nothing.

In a future world, we should detect the case of "would we use a plugin document for this?" earlier and cut off the load, and do so as early as possible after we know the mime type.

[Brady Eidson]

Filed https://bugs.webkit.org/show_bug.cgi?id=39330 to followup and make this more perfect later (patch is coming up shortly)

[Brady Eidson]

Created attachment 56422 [details]
Proposed fix + test

Replace any PluginDocuments that violate sandboxing with a new document/tokenizer that acts as a data sink, just ignoring the resource data.

This prevents the crash and prevents the plugin binaries from loading.

[Maciej Stachowiak]

Comment on attachment 56422 [details]
Proposed fix + test

r=me

[Brady Eidson]

http://trac.webkit.org/changeset/59719