1254434 - crash with iframe sandbox and about: URLs (nsAString_internal::Assign | nsAString_internal::Assign | mozilla::dom::OriginAttributesDictionary::operator=)

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Attachment: crashPoC.html

Found a reproducible crash when looking at <iframe sandbox>.  The attached file loads an <iframe sandbox="allow-scripts">, which then attempts to embed a frame with an 'about:' url. The nested iframe doesn't load but if you then open devtools, and then reload the page, the browser crashes. Crash 44.0.2 and nightly. Crash URL linked above. The crash looks 'XPConnect-ish', hence the component, but that's a wild guess. 

STR:
1. load the attached file
2. open devtools panel
3. reload the page

Sometimes I need to repeat the reload step 1 or 2 times, but usually this crashes first time. 
Marked as sensitive until someone's sure its not. STR relies on user interaction but its 100% reproducible.

Comment 1

[Bob Owen (:bobowen)]

This is being caused by GetInheritedPrincipal at [1] returning null.
I think GetInheritedPrincipal is returning null because mParent is null.

This gets passed into CreateAboutBlankContentViewer and further down gets cast at [2], and so points into invalid memory.

DumpJSStack at [1] gives:

0 DebuggerProgressListener.prototype._getWindowsInDocShell/<(d = [xpconnect wrapped (nsISupports, nsIDocShell, nsIInterfaceRequestor, nsIWebProgress) @ 0xc3ff3a0 (native @ 0x897cc04)], 0, [xpconnect wrapped (nsISupports, nsIDocShell, nsIInterfaceRequestor, nsIWebProgress) @ 0xc3ff3a0 (native @ 0x897cc04)]) ["resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webbrowser.js":2207]
1 map(callbackfn = d => {
      return d.QueryInterface(Ci.nsIInterfaceRequestor)
              .getInterface(Ci.nsIDOMWindow);
    }) ["self-hosted":256]
    this = [xpconnect wrapped (nsISupports, nsIDocShell, nsIInterfaceRequestor, nsIWebProgress) @ 0xc3ff3a0 (native @ 0x897cc04)]
2 DebuggerProgressListener.prototype._getWindowsInDocShell(docShell = [xpconnect wrapped (nsISupports, nsIDocShell, nsIInterfaceRequestor, nsIWebProgress) @ 0xc3ff3a0 (native @ 0x897cc04)]) ["resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webbrowser.js":2206]
    this = [object Object]
3 DebuggerProgressListener.prototype.watch(docShell = [xpconnect wrapped (nsISupports, nsIDocShell, nsIInterfaceRequestor, nsIWebProgress) @ 0xc3ff3a0 (native @ 0x897cc04)]) ["resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webbrowser.js":2181]
    this = [object Object]
4 TabActor.prototype._onDocShellCreated/<() ["resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webbrowser.js":1164]
5 exports.makeInfallible/<() ["resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js":101]
    this = [object Object]


[1] https://dxr.mozilla.org/mozilla-central/rev/be593a64d7c6a826260514fe758ef32a6ee580f7/docshell/base/nsDocShell.cpp#7833
[2] https://dxr.mozilla.org/mozilla-central/rev/be593a64d7c6a826260514fe758ef32a6ee580f7/caps/nsNullPrincipal.cpp#42

Comment 2

[Bobby Holley (:bholley)]

Yes, we probably need a null-check in there somewhere, since GetInheritedPrincipal has explicit null returns. Not sure exactly where though.

Comment 3

[Matt Wobensmith [:mwobensmith][:matt:]]

Pre-CritSmash triage group, revising rating to sec-low, based on user interaction with dev tools.

Comment 4

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.