Assigning to the concern owner from Predator results --
Regression information is not available. The result is the blame information. 

Author: brettw@google.com
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/d028296ec1c0fdfbd40e2390ca3121de7055295d
Time: Sat Jan 01 16:08:52 2011
The CL last changed line 18 of file debugger_win.cc, which is stack frame 0. 

Author: rch@chromium.org
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/82d89abc03ea6fd6b9258f0e57be0290b33d7eb1
Time: Fri Feb 28 18:25:34 2014
The CL last changed line 783 of file logging.cc, which is stack frame 1. 

Author: mkwst
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/25ec43232e79ebfe0c4fdd2e301d957268c66e26
Time: Thu Nov 03 13:47:47 2016
The CL last changed line 4999 of file render_frame_impl.cc, which is stack frame 2. 

Author: sashab
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/2fc8938d50be3bb9bdfcb9bffec230843b54122c
Time: Thu Apr 20 07:38:22 2017
The CL last changed line 3714 of file render_frame_impl.cc, which is stack frame 3. 

Author: sashab
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/2fc8938d50be3bb9bdfcb9bffec230843b54122c
Time: Thu Apr 20 07:38:22 2017
The CL last changed line 4024 of file render_frame_impl.cc, which is stack frame 4. 

Author: sashab
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/4cb985fa6d89b720370db447dd12c46fabab2ab0
Time: Tue Apr 18 02:58:47 2017
The CL last changed line 162 of file web_frame_test_proxy.h, which is stack frame 5.

@brettw -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

This might also be occurring in WebView in an internally reported bug: b/34220171

Nasko, this is crashing on your URL vs Origin CHECK:

[1736:2308:0615/170940.119:4949937:FATAL:render_frame_impl.cc(4999)] Check failed: params.origin.IsSamePhysicalOriginWith(url::Origin(params.url)).  url:http://127.0.0.1:8000/resources/redirect.php?url=http://localhost:8000/history/resources/back.html origin:file://

Here's the source link:
https://chromium.googlesource.com/chromium/src/+/b555b8a9c2e7b5fb5615fc422c905d35e602b258/content/renderer/render_frame_impl.cc#4999

The test seems to be opening a file URL in a layout test context, which gives it allow_universal_access_from_files (and thus the ability to do a pushState from a file:// origin to a web origin).  However, the test has these lines:

   testRunner.setAllowUniversalAccessFromFileURLs(false);
   history.pushState({}, "", "http://127.0.0.1:8000/resources/redirect.php?url=http://localhost:8000/history/resources/back.html");

That call to setAllowUniversalAccessFromFileURLs(false) seems to be the problem.  Apparently it's not kicking in immediately.  Maybe it's asynchronous and involves a trip to the browser process?  Nasko's check assume it will take effect immediately, though, so it kills the renderer process.  Maybe there's a way to make the two cases agree (e.g., make it take effect sooner, or make the check see the old value until the change takes effect)?


Comment 2: Yes, that bug is crashing in the same place.  I bet it's a loadDataWithBaseURL issue in Android Webview, with a slightly different cause than this layout test framework issue.

One of the first things done by the Blink implementation of history.pushState is to check the URL via History::CanChangeToUrl which (among other things) consults document_origin->IsGrantedUniversalAccess() - this flag is stored inside blink::SecurityOrigin::universal_access_ boolean field.

It turns out that calling testRunner.setAllowUniversalAccessFromFileURLs(false) affects blink::SecurityOrigin::universal_access_ of *future* origins, but doesn't retroactively reset this flag in *already existing* origins.  Granting of universal access to origins associated with a *new* document happens in Document::InitSecurityContext (below), but AFAICT there is no code that revokes universal access to already existing documents/origins.

  void Document::InitSecurityContext(...) {
    ...
    if (!settings->GetWebSecurityEnabled()) {
      // Web security is turned off. We should let this document access every
      // other document. This is used primary by testing harnesses for web
      // sites.
      GetSecurityOrigin()->GrantUniversalAccess();
    } else if (GetSecurityOrigin()->IsLocal()) {
      if (settings->GetAllowUniversalAccessFromFileURLs()) {
        // Some clients want local URLs to have universal access, but that
        // setting is dangerous for other clients.
        GetSecurityOrigin()->GrantUniversalAccess();
      } else if (!settings->GetAllowFileAccessFromFileURLs()) {
        // Some clients do not want local URLs to have access to other local
        // URLs.
        GetSecurityOrigin()->BlockLocalAccessFromLocalOrigin();
      }
    }


So, given above, I think the observed behavior is expected - the fuzzer created a testcase that misuses test-only APIs (i.e. calling testRunner.setAllowUniversalAccessFromFileURLs without later loading a new document) and created a situation where 2 pieces of code (already-existing origin, global settings) disagree, leading to a security-related CHECK.

Thanks, that helps clarify what I was observing!  If this flag were used a lot in practice, it might be worth revoking the privilege from existing origins, but it doesn't seem worth the effort or complexity for just for test code (or other places where the mode is unlikely to change at runtime).

I do wonder if this will be unexpected for test authors.  Maybe it's worth documenting in test_runner.h that it only affects origins created after the call?

Apart from that, I'd be ok with WontFixing this, since it doesn't seem like it would affect actual Chrome.

ClusterFuzz testcase 5038230029467648 is flaky and no longer crashes, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.