cross-frame-access-call.html and promise-realm.html are failing on Site Isolation Linux FYI bot |
|||
Issue descriptionThese tests are hitting a DCHECK on Site Isolation Linux: http/tests/security/promise-realm.html http/tests/security/cross-frame-access-call.html First failing Linux build: https://build.chromium.org/p/chromium.fyi/builders/Site%20Isolation%20Linux/builds/13762 Looks like this is from LocalDOMWindow's DEFINE_TYPE_CASTS. cross-frame-access-call.html output: STDERR: [4:4:0203/123926.639106:3624582560:FATAL:LocalDOMWindow.h(377)] Security DCHECK failed: !x || (x->isLocalDOMWindow()). STDERR: #0 0x00000191cc77 base::debug::StackTrace::StackTrace() STDERR: #1 0x00000192fd9b logging::LogMessage::~LogMessage() STDERR: #2 0x000002ba72b8 blink::DOMWindowV8Internal::setTimeout2Method() STDERR: #3 0x0000007c1cf3 v8::internal::FunctionCallbackArguments::Call() STDERR: #4 0x000000869c4c v8::internal::(anonymous namespace)::HandleApiCallHelper<>() STDERR: #5 0x000000868802 v8::internal::Builtin_Impl_HandleApiCall() STDERR: #6 0x3e592270420e <unknown> promise-realm.html output: STDERR: [4:4:0203/123930.782242:3628725749:FATAL:LocalDOMWindow.h(377)] Security DCHECK failed: !x || (x->isLocalDOMWindow()). STDERR: #0 0x00000191cc77 base::debug::StackTrace::StackTrace() STDERR: #1 0x00000192fd9b logging::LogMessage::~LogMessage() STDERR: #2 0x00000388c064 blink::V8WindowPartial::fetchMethodCallback() STDERR: #3 0x0000007c1cf3 v8::internal::FunctionCallbackArguments::Call() STDERR: #4 0x000000869c4c v8::internal::(anonymous namespace)::HandleApiCallHelper<>() STDERR: #5 0x000000868802 v8::internal::Builtin_Impl_HandleApiCall() STDERR: #6 0x0e13f020420e <unknown> From the blamelist, I'm suspecting https://codereview.chromium.org/2668753006. Daniel, can you please take a look?
,
Feb 7 2017
I think the problem is a bad interaction between partial interfaces and the patch I landed. The generated code looks like this:
// Same-origin methods are never exposed via the cross-origin interceptors.
// Since same-origin access requires a LocalDOMWindow, it is safe to downcast
// here.
LocalDOMWindow* impl = toLocalDOMWindow(V8Window::toImpl(info.Holder()));
if (!BindingSecurity::shouldAllowAccessTo(currentDOMWindow(info.GetIsolate()), impl, exceptionState)) {
return;
}
So my original assumption that we can't reach these code paths for a cross-origin window is incorrect. I guess what's happening is a context captures a reference to window.setTimeout and then invokes it after navigating it cross-origin. Doh.
,
Feb 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ae9143a9d87c734f5b31f72f296917cc8bc24588 commit ae9143a9d87c734f5b31f72f296917cc8bc24588 Author: dcheng <dcheng@chromium.org> Date: Wed Feb 08 05:50:31 2017 Bindings: perform security check before downcasting to LocalDOMWindow. Certain callbacks can be reached after the browsing context has been navigated. In those instances, it's important to do the security check before downcasting, since the normal security check on the holder object won't be used. BUG= 689243 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation Review-Url: https://codereview.chromium.org/2683583003 Cr-Commit-Position: refs/heads/master@{#448915} [modify] https://crrev.com/ae9143a9d87c734f5b31f72f296917cc8bc24588/third_party/WebKit/Source/bindings/templates/attributes.cpp.tmpl [modify] https://crrev.com/ae9143a9d87c734f5b31f72f296917cc8bc24588/third_party/WebKit/Source/bindings/templates/methods.cpp.tmpl [modify] https://crrev.com/ae9143a9d87c734f5b31f72f296917cc8bc24588/third_party/WebKit/Source/web/tests/WebFrameTest.cpp
,
Feb 8 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by dcheng@chromium.org
, Feb 6 2017