This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hello Mojo owners!

I need your help finding an appropriate owner for this security bug in mojo comms (ipc?).  Maybe javascript related (based on the fuzzer name)?  I've CC'd Kentaro for blink>javascript eyes.  

Ken, you're the lucky winner of the "owner" lottery.  Feel free to adjust labels.

Thank you very much!


+marty - what's happened with this "regressed:" value in this clusterfuzz ticket?  Is it supposed to be a link to a range?

Adding some other people who know lots of things. yzshen@ for MultiplexRouter, mek@ for BroadcastChannel. Haven't looked at this yet but FYI

De-duping from  bug 647387 . For some additional context here, this is ultimately a result of blink continuing to hold references to mojo bindings objects after blink::shutdown() has been called. If it's at all possible, we should stop that from happening.

Failing that, we can concoct a ham-fisted solution for killing all bindings before shutting down the Message Loop, or maybe globally disabling the connection error notifications on MessageLoop shutdown.

Is there a way to identify the Blink object that's holding the bad reference?

The MSan trace is:

==1==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x49b0d0c in CreateHandle v8/src/handles-inl.h:103:7
    #1 0x49b0d0c in CreateHandle v8/src/api.cc:886:0
    #2 0x120573fd in New v8/include/v8.h:8266:40
    #3 0x120573fd in New v8/include/v8.h:8257:0
    #4 0x120573fd in context gin/public/context_holder.h:37:0
    #5 0x120573fd in Scope gin/runner.cc:18:0
    #6 0xab96f72 in OnHandleReady mojo/edk/js/waiting_callback.cc:72:22
    #7 0x3c2dcc4 in Run base/callback.h:64:12
    #8 0x3c2dcc4 in OnHandleReady mojo/public/cpp/system/watcher.cc:122:0
    #9 0x3c2dcc4 in WillDestroyCurrentMessageLoop mojo/public/cpp/system/watcher.cc:32:0
    #10 0xaed33dc in ~MessageLoop base/message_loop/message_loop.cc:174:3
    #11 0xaecaa4c in ?? base/message_loop/message_loop.cc:139:29
    #12 0x1c2de68d in operator() buildtools/third_party/libc++/trunk/include/memory:2529:13
    #13 0x1c2de68d in reset buildtools/third_party/libc++/trunk/include/memory:2735:0
    #14 0x1c2de68d in Shutdown content/renderer/render_thread_impl.cc:981:0
    #15 0x16469972 in ~ChildProcess content/child/child_process.cc:73:19

  Uninitialized value was created by a heap deallocation
    #0 0x768ca2 in operator delete(void*) ??:0
    #1 0x60eab66 in TearDown v8/src/isolate.cc:2029:3
    #2 0x1f02716f in ~IsolateHolder gin/isolate_holder.cc:75:13
    #3 0x170ebfee in operator() buildtools/third_party/libc++/trunk/include/memory:2529:13
    #4 0x170ebfee in reset buildtools/third_party/libc++/trunk/include/memory:2735:0
    #5 0x170ebfee in ~unique_ptr buildtools/third_party/libc++/trunk/include/memory:2703:0
    #6 0x170ebfee in ~V8PerIsolateData third_party/WebKit/Source/bindings/core/v8/V8PerIsolateData.cpp:79:0
    #7 0x170ed43c in destroy third_party/WebKit/Source/bindings/core/v8/V8PerIsolateData.cpp:258:5
    #8 0x16d7e9fe in shutdown third_party/WebKit/Source/web/WebKit.cpp:113:5
    #9 0x1c2de5fd in Shutdown content/renderer/render_thread_impl.cc:970:5
    #10 0x16469972 in ~ChildProcess content/child/child_process.cc:73:19

which doesn't point at anything in Blink. A CHECK showing a FROM_HERE value for the creation of the WaitingCallback would really help.

I suspect a FROM_HERE won't help much. IIRC, FROM_HERE doesn't record callstack, and the only place of creating WaitingCallback is WaitingCallback::Create().

(And WaitingCallback::Create() is used by some generic API exposed to JS.)

This bug is reported as M55 Beta blocker.Please try to resolve this before M55 branch on Oct 6th,2016 so it has enough baking time in Dev.

rockot: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

A friendly reminder that M55 Beta launch is coming soon! Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix ASAP. Thank you.

The fuzzer seems to be confused because typically it produces V8 crashers. In that case, it is not a crash in V8 bug mojo.

**** Bulk edit -  please ignore if not applicable ****

This bug  is reported as M55 Beta blocker and we're getting closer to M55 Beta promotion. 
Please plan to have fix ready and merged to M55 branch (2883) by 5:00 PM PT, Monday(10/10) so it has enough baking time in Dev before Beta promotion. Thank you.

ClusterFuzz has detected this issue as fixed in range 40535:40553.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4897165422100480

Fuzzer: mbarbella_js_mutation_layout
Job Type: linux_asan_chrome_v8_ignition
Platform Id: linux

Crash Type: UNKNOWN READ
Crash Address: 0x7e93073ca948
Crash State:
  mojo::InterfaceEndpointClient::NotifyError
  mojo::internal::MultiplexRouter::ProcessTasks
  mojo::internal::MultiplexRouter::OnPipeConnectionError
  
Recommended Security Severity: Medium

Regressed: V8: r37851:37885
Fixed: V8: r40535:40553

Minimized Testcase (0.08 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv94kPJzzfMVQ3cBtnD1wgZKwuXHp40FaGGMI_GtMgtYOBYbn3d1MVEtBQwq-kneyCeeDsLuDJ6-1ngCBkLkEpf79CEuG24gk9PCN48q-w5mG-rof0bFOLg2KyEyJlL9-JW_EZEfUIu3eGfQIiuODQitGwcW-rQ?testcase_id=4897165422100480
<script>
  let __v_0 = new BroadcastChannel('foo');
window.close();
  </script>


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot