2052581 - Content-process crash [@ mozilla::dom::BrowsingContextGroup::EnsureUsesOriginAgentClusterInitialized] loading about:blank into a sandboxed iframe

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Tyson Smith [:tsmith]]

Found with m-c 20260511-baf3d19d5c8e.

A web-content-reachable content-process crash hits a release assertion:

MozCrashReason: MOZ_RELEASE_ASSERT(!XRE_IsContentProcess()) (Cannot determine origin-keying in content process!)

Stack (top frames):

  0 xul.dll mozilla::dom::BrowsingContextGroup::EnsureUsesOriginAgentClusterInitialized(nsIPrincipal*)  docshell/base/BrowsingContextGroup.cpp:758
  1 xul.dll nsDocShell::CreateAboutBlankDocumentViewer(...)  docshell/base/nsDocShell.cpp:6503
  2 xul.dll nsDocShell::CompleteInitialAboutBlankLoad(nsDocShellLoadState*, nsILoadInfo*)  docshell/base/nsDocShell.cpp:10079
  3 xul.dll nsDocShell::DoURILoad(...)
  4 xul.dll nsDocShell::InternalLoad(...)
  5 xul.dll nsDocShell::LoadURI(...)
  6 xul.dll mozilla::dom::BrowsingContext::LoadURI(...)  docshell/base/BrowsingContext.cpp:2302
  7 xul.dll mozilla::dom::ContentChild::RecvLoadURI(...)  dom/ipc/ContentChild.cpp:4357

Root cause:

BrowsingContextGroup::EnsureUsesOriginAgentClusterInitialized asks UsesOriginAgentCluster(aPrincipal) whether the origin-keying decision is already known for the principal. If that returns Nothing(), it asserts it must be in the parent process, since only the parent can authoritatively decide origin-keying (it owns process-switching and observes the network Origin-Agent-Cluster header):

if (UsesOriginAgentCluster(aPrincipal).isSome()) return;
MOZ_RELEASE_ASSERT(!XRE_IsContentProcess(),
                   "Cannot determine origin-keying in content process!");

The invariant is that by the time a content process needs to create a document for a principal, the parent has already populated mUseOriginAgentCluster for it. This crash is that invariant being violated. UsesOriginAgentCluster already carries a MOZ_DIAGNOSTIC_ASSERT comment noting the parent may have chosen not to process-switch, which is exactly the hole being hit.

Trigger (a sandboxed iframe loading about:blank):

1. A sandboxed iframe without allow-same-origin gets its initial about:blank document created with a NullPrincipal (from sandbox flags).
2. The src="about:blank" load arrives in the content process via RecvLoadURI, where aLoadState->PrincipalToInherit() is the parent frame's content (http) principal.
3. In CompleteInitialAboutBlankLoad (nsDocShell.cpp:10090), expectedPrincipal (content principal) does not match the document's NullPrincipal, so principalMismatch == true, and the code calls CreateAboutBlankDocumentViewer(expectedPrincipal, ...) to clobber the document (nsDocShell.cpp:10111).
4. CreateAboutBlankDocumentViewer unconditionally calls EnsureUsesOriginAgentClusterInitialized(aPrincipal) at nsDocShell.cpp:6509 with that content principal.
5. For this sandboxed-iframe about:blank load the parent never process-switched and never seeded the OAC decision for that content principal in this content process, so UsesOriginAgentCluster returns Nothing() and the release assert fires.

Steps to reproduce (HTML):

    <iframe sandbox src="about:blank"></iframe>
    <iframe sandbox="allow-scripts" src="about:blank"></iframe>
    <script>
      var ifr = document.createElement("iframe");
      ifr.sandbox = "";
      ifr.src = "about:blank";
      document.body.appendChild(ifr);
    </script>

Severity/impact: web-content-triggerable content-process (renderer) crash / DoS. Release assert, so it fires in shipping builds. No memory-safety implication.

Possible fix direction: the sandbox/principal-mismatch clobber path for an initial about:blank should not demand an origin-keying decision only the parent can make. Either skip EnsureUsesOriginAgentClusterInitialized for the synchronous sandbox-clobber case, or handle the content-process Nothing() result gracefully when the effective document principal will be a NullPrincipal anyway. Since the effective document principal ends up sandboxed (NullPrincipal), keying OAC on the content principal is arguably wrong here regardless of the crash.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Sorry, vhilla, another about:blank thingie

Comment 2

[Vincent Hilla [:vhilla]]

Oh, interesting. I thought I fixed this in bug 2004165. Keeping the ni?

Edit: Ah, that fix was only for loads from SH.

Comment 3

[Vincent Hilla [:vhilla]]

:tsmith, I can't reproduce this following the steps.

The report sounds like LLM. If so, how was this generated? Were you able to reproduce? Is the LLM guaranteed to have reproduced it? Given it blocks site-scout, is there a site I can visit to reproduce it?

---

The src="about:blank" load arrives in the content process via RecvLoadURI

I don't think a sandboxed about:blank iframe would usually go through the parent.

Comment 4

[Tyson Smith [:tsmith]]

Yes it was LLM generated, I logged a batch of unreproducible but consistently reported site-scout issues that looked like genuine issues. I should have stripped that testcase it added. Hopefully this is actionable.

I have seen this reported 11 times so far (since 2026-05-11) and reported as recently as yesterday (2026-07-05). None of the sites that have been reported will reproduce the issue (some are top 10K and are tested multiple times per week on multiple platforms and builds). I have seen this reported on Windows, Linux and Android on debug and ASan opt builds. The issue is usually reported in <5 seconds of the page load start sometime taking up to 20 seconds. An example URL is http://id.xhcopy.life/.

Comment 5

[Tyson Smith [:tsmith]]

Attachment: stack.txt

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Vincent Hilla [:vhilla] from comment #3)

The src="about:blank" load arrives in the content process via RecvLoadURI

I don't think a sandboxed about:blank iframe would usually go through the parent.

But what if the parent explicitly loads about:blank? Say, even a cross-site parent

Comment 7

[Vincent Hilla [:vhilla]]

https://treeherder.mozilla.org/jobs?repo=try&revision=0ab58a356db6c0e75c3a8984c2302e7587276716

Try push to see what hits BrowsingContext::LoadURI with about:blank in the parent.

• /content-security-policy/inheritance/history-iframe.sub.html
• /content-security-policy/inheritance/history.sub.html
• /content-security-policy/inheritance/window-open-local-after-network-scheme.sub.html
• /html/infrastructure/urls/base-url/document-base-url-initiated-grand-parent.https.window.html
• toolkit/components/extensions/test/mochitest/test_ext_webnavigation_filters.html
• toolkit/components/extensions/test/mochitest/test_ext_webnavigation_filters.html
• dom/base/test/test_window_cross_origin_props.html
• toolkit/components/extensions/test/mochitest/test_ext_webnavigation_filters.html
• docshell/test/navigation/test_aboutblank_change_process.html

Comment 8

[Vincent Hilla [:vhilla]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #6)

(In reply to Vincent Hilla [:vhilla] from comment #3)

The src="about:blank" load arrives in the content process via RecvLoadURI

I don't think a sandboxed about:blank iframe would usually go through the parent.

But what if the parent explicitly loads about:blank? Say, even a cross-site parent

The parent would have to load about:blank with a principal for which OAC isn't initialized in that process, and in a docshell that didn't load anything else before. That might be possible as a browser chrome test, but I don't see why the parent process would want to do this. Or how a parent document would achieve this.

---

Maybe there is a race window where foo loads bar, bar loads in a different process. Between process switch and starting the load, something manages to get an about:blank load with foo origin in. The iframe is cross origin, about:blank goes through IPC, mHasStartedLoadingOtherThanInitialBlankURI isn't set yet and thus we end up loading an initial about:blank with foo origin in the bar process. In that process OAC wouldn't be initialized for foo. Though we do check ValidatePrincipalCouldPotentiallyBeLoadedBy in ShouldDoInitialAboutBlankSyncLoad, which makes this more confusing.

I'm unable to create a test for that. Also can't reproduce this on http://id.xhcopy.life/, which would hint towards a race.

Anyway, I think we should remove the aLoadState->LoadIsFromSessionHistory() condition in ShouldDoInitialAboutBlankSyncLoad. Considering this comment, if OAC isn't initialized we might want to do a process switch and should take the regular load path. The alternative, initializing OAC in SendLoadURI or so, especially without understanding when these crashes happen, doesn't seem good to me.

---

Some crashes happen on ESR, which bug 543435 hasn't reached yet. I see those pre-existing ones going through CreateAboutBlankDocumentViewer. It could even be that this is a pre-existing issue that got more likely with bug 543435 making about:blank load in less event loop ticks.

I see crashes coming from RecvLoadURI but also MaybeInitializeFinalizeFrameLoaders, i.e. both top-level and iframes might be impacted.

https://crash-stats.mozilla.org/report/index/f78bf6f0-cae4-40f0-aeb9-cac230260705 is close to startup but from the stack, doesn't involve SH or IPC. JS adds an iframe, we start loading it and hit the crash, which is very strange to me.