ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=5179819644157952

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=6336021887451136

I'm having trouble reproducing this. If you could provide a minimal test case that reproduces this consistently, I'd be happy to take another look. Ideally we'd prefer to have this as an html file attached to this report rather than something hosted live.

Sorry for the delay. First, the SIGSEGV signal was missleading. It was causing of using -singleprocess, which is not supported anymore. In any case, I managed to minimize the test case to a single file big html file loading from an iframe.

In Google Chrome 55.0.2883.11, download both files, open crash.html and wait. It takes around 10 minutes here. The tab should crash (Oh Snap!) and you can get this message in the kernel ring buffer (dmesg):

[108682.243225] traps: chrome[14015] trap invalid opcode ip:55c07c09ed11 sp:7fff492792d0 error:0 in chrome[55c0794b7000+64ed000]

In case you cannot reproduce, let me know and i will report this directly to the ArchLinux security team.

Regards,
Gustavo.

(i'm attaching the file as a zip, since i'm having trouble with a 1.8MB of html)

Deleted: crash.zip 16.9 KB

crash.zip 16.9 KB Download

Still not reproducing?

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=6169312365903872

This looks a lot like an OOM to me.

Uhm, i carefully monitored the memory consumption while the POC is loading. I don't see any abnormal memory use. Maybe it is allocating more than 1GB at once and it is aborted by the chromium allocation function?

Thanks gustavo. I can reproduce it on ff8927d999b60047b7b016fa41bc7d5e0d438756. Here's the stacktrace:

```
[101868:101868:1031/160159:FATAL:render_widget_host_view_base.cc(165)] Check failed: showing_context_menu_ != showing (1 vs. 1)
#0 0x7fc1fba9b53e base::debug::StackTrace::StackTrace()
#1 0x7fc1fbb0aa6f logging::LogMessage::~LogMessage()
#2 0x7fc1f5c486ba content::RenderWidgetHostViewBase::SetShowingContextMenu()
#3 0x7fc200510f3a RenderViewContextMenuBase::MenuWillShow()
#4 0x7fc1f8c8eca3 ui::SimpleMenuModel::MenuWillShow()
#5 0x7fc1ef01886c views::MenuModelAdapter::WillShowMenu()
#6 0x7fc1ef003850 views::MenuController::OpenMenuImpl()
#7 0x7fc1ef0037b5 views::MenuController::OpenMenu()
#8 0x7fc1ef001f55 views::MenuController::CommitPendingSelection()
#9 0x7fc1eeffbc22 views::MenuController::SetSelection()
#10 0x7fc1eeffb295 views::MenuController::Run()
#11 0x7fc1ef01bab4 views::internal::MenuRunnerImpl::RunMenuAt()
#12 0x7fc1ef01aed6 views::MenuRunner::RunMenuAt()
#13 0x7fc2005167b5 ToolkitDelegateViews::RunMenuAt()
#14 0x7fc20032f5f6 RenderViewContextMenuViews::RunMenuAt()
#15 0x7fc200330347 RenderViewContextMenuViews::Show()
#16 0x7fc2000785b1 ChromeWebContentsViewDelegateViews::ShowMenu()
#17 0x7fc200078641 ChromeWebContentsViewDelegateViews::ShowContextMenu()
#18 0x7fc1f5f65fb7 content::WebContentsViewAura::ShowContextMenu()
#19 0x7fc1f5f35fda content::WebContentsImpl::ShowContextMenu()
#20 0x7fc1f565811b content::RenderFrameHostImpl::OnContextMenu()
#21 0x7fc1f567646d _ZN4base20DispatchToMethodImplIPN7content19RenderFrameHostImplEMS2_FvRKNS1_17ContextMenuParamsEERKSt5tupleIJS4_EEJLm0EEEEvRKT_T0_OT1_NS_13IndexSequenceIJXspT2_EEEE
#22 0x7fc1f56763c0 _ZN4base16DispatchToMethodIPN7content19RenderFrameHostImplEMS2_FvRKNS1_17ContextMenuParamsEERKSt5tupleIJS4_EEEEvRKT_T0_OT1_
#23 0x7fc1f567633f _ZN3IPC16DispatchToMethodIN7content19RenderFrameHostImplEMS2_FvRKNS1_17ContextMenuParamsEEvSt5tupleIJS3_EEEEvPT_T0_PT1_RKT2_
#24 0x7fc1f5666ec0 _ZN3IPC8MessageTI29FrameHostMsg_ContextMenu_MetaSt5tupleIJN7content17ContextMenuParamsEEEvE8DispatchINS3_19RenderFrameHostImplES8_vMS8_FvRKS4_EEEbPKNS_7MessageEPT_PT0_PT1_T2_
#25 0x7fc1f5654332 content::RenderFrameHostImpl::OnMessageReceived()
#26 0x7fc1f5bb7352 content::RenderProcessHostImpl::OnMessageReceived()
#27 0x7fc1f8a21808 IPC::ChannelProxy::Context::OnDispatchMessage()
#28 0x7fc1f8a280cf _ZN4base8internal13FunctorTraitsIMN3IPC12ChannelProxy7ContextEFvRKNS2_7MessageEEvE6InvokeIRK13scoped_refptrIS4_EJS7_EEEvS9_OT_DpOT0_
#29 0x7fc1f8a27fb6 _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKMN3IPC12ChannelProxy7ContextEFvRKNS4_7MessageEEJRK13scoped_refptrIS6_ES9_EEEvOT_DpOT0_
#30 0x7fc1f8a27f43 _ZN4base8internal7InvokerINS0_9BindStateIMN3IPC12ChannelProxy7ContextEFvRKNS3_7MessageEEJ13scoped_refptrIS5_ES6_EEEFvvEE7RunImplIRKSA_RKSt5tupleIJSC_S6_EEJLm0ELm1EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE
#31 0x7fc1f8a27e5c _ZN4base8internal7InvokerINS0_9BindStateIMN3IPC12ChannelProxy7ContextEFvRKNS3_7MessageEEJ13scoped_refptrIS5_ES6_EEEFvvEE3RunEPNS0_13BindStateBaseE
#32 0x7fc1fbaa1421 _ZNO4base8internal8RunMixinINS_8CallbackIFvvELNS0_8CopyModeE0ELNS0_10RepeatModeE0EEEE3RunEv
#33 0x7fc1fbaa0e29 base::debug::TaskAnnotator::RunTask()
#34 0x7fc1fbb3392a base::MessageLoop::RunTask()
#35 0x7fc1fbb33bb4 base::MessageLoop::DeferOrRunPendingTask()
#36 0x7fc1fbb33e9e base::MessageLoop::DoWork()
#37 0x7fc1fbb4c3b6 base::MessagePumpGlib::Run()
#38 0x7fc1fbb334aa base::MessageLoop::RunHandler()
#39 0x7fc1fbbdb604 base::RunLoop::Run()
#40 0x7fc1fe01a4df ChromeBrowserMainParts::MainMessageLoopRun()
#41 0x7fc1f5327339 content::BrowserMainLoop::RunMainMessageLoopParts()
#42 0x7fc1f5332c95 content::BrowserMainRunnerImpl::Run()
#43 0x7fc1f5320f08 content::BrowserMain()
#44 0x7fc1f6a8b736 content::RunNamedProcessTypeMain()
#45 0x7fc1f6a8d7e2 content::ContentMainRunnerImpl::Run()
#46 0x7fc1f6a8aa22 content::ContentMain()
#47 0x7fc1fc9121db ChromeMain
#48 0x7fc1fc912172 main
#49 0x7fc1e8becf45 __libc_start_main
#50 0x7fc1fc912075 <unknown>

Aborted (core dumped)

 Issue 636041  has been merged into this issue.

avi@, I wonder if you could take a look at this. Thanks!

It doesn't look like a security bug though.

Am not an Aura/Views peep. Peter?

But Avi, you wrote the code (specifically, the DCHECK and the function containing it) in question: https://chromiumcodereview.appspot.com/9316073

(sky probably knows more about menus in views than me, FWIW.)

+jonross as he's changed menus around recently.

The repro at the original link is gone; I'm talking about the repro in comment 5.

What we have is a top-level page with an iframe, and in the iframe is loaded about 1.8MB of tag soup. Loading the page chews up memory until it tops out (for me) at about 2GB. No crashes on Canary on either Windows or Mac, but I don't have a Linux machine.

Tanin, re comment 10, your backtrace looks weird because it's a triggering of a context menu, but the page shouldn't be able to do that.

Can you confirm that you're not right-clicking or interfering at all?

(Scott, do you have a Linux machine?)

avi, I do have a linux machine can can certainly try to repro something if you need me to. As with you, I am equally surprised the page would be triggering a context menu by itself.

I'm a bit concerned about trying an artibrary zip file attached to this bug. Are we sure that doesn't have any security issues?

That menu stack trace would be triggered by a right-click. That's the expected handling of the IPC message from the content area.

The crash implies that RenderFrameImpl is telling us to open the context menu while it's alright opened. However a second right-click should dismiss the active one.

Do we have a minimal webpage that replicates that crash?

I also have a linux machine to test on

I just repro-d the menu crash on ToT Linux.
   1) Navigate to a long loading page, like the twitter homepade
   2) Spam right-click

On debug builds a DCHECK fires. I can look into the root cause, but it's not a crash that occurs in release. On release the menu opens/closes as expected.

Based on avi's comment in #18 I suspect that we have two different issues here

I've filled  issue 661595  and assigned it to me to take a look at the DCHECK

Just to clarify: the crashes/aborts we detected required no interaction at all.

Gustavo, what is crashing? Your original report said the tab was crashing, but comment 5 talks about the browser crashing.

The tab crashes/aborts (Oh Snap!) while loading or just after finishing loading the test case. Sorry if i was not clear enough before.

OK. You're experiencing a renderer crash, and comment 10 is a browser crash. Therefore, comment 10 is not what's happening here.

The crash from comment 10 was split off into  issue 661595 , and jonross@ is looking at it.

That leaves us with the original renderer crash. Gustavo, do you have a crash id?

I do not have it. I will try to get it from Chrome from my Linux box later today. I assume you cannot reproduce my original tab crash, right?

I can't repro on either Mac or Windows. Scott, can you repro on Linux?

I tried on my linux machine, both debug and release builds, and after ~10 minutes no crash but the tab is still loading. This is with a tip of tree build.

My release build (with dchecks enable) did eventually finish loading the page and didn't crash.

Crash ID: crash/cce874c700000000

Gustavo, thank you. You're crashing at:

	0x0000558792853f22	(chrome -./out/Release/../../third_party/WebKit/Source/platform/heap/HeapPage.cpp:509 )	<name omitted>

That is https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/heap/HeapPage.cpp?q=heappage&dr=C&l=509 :

      if (!pageMemory) {
        bool result = memory->commit();
        // If you hit the ASSERT, it will mean that you're hitting
        // the limit of the number of mmapped regions OS can support
        // (e.g., /proc/sys/vm/max_map_count in Linux).
        RELEASE_ASSERT(result);  // <-- line 509
        pageMemory = memory;
      } else {

It looks like your particular Linux distro has a low limit on mmapped regions. Sending this to haraken@ who knows this area and can make sure we're doing the right thing here. Investigation of the context menu issue will continue in the other bug.

Then won't this be just OOM?

Is running out of mmapable regions equivalent to an OOM situation? If so I'm OK calling this WAI.

Yes, it's a kind of OOM -- address overflow.

If this is happening without allocating a lot of memory, it's problematic. Otherwise, there's nothing we can do here. (Note: We could probably implement a global address-space coordinator to decrease address-space segmentation though.)

This is a fuzzer-generated HTML file that loads hundreds of frames. On Mac/Windows, it chews up 2 gigs of RAM, so I also feel OK calling this intentional.

Thank you, haraken.

Gustavo, I'm closing this as intentional crashing. haraken, do you want to file a bug about being more careful about running out of address space segments?

Fair enough. Thanks for taking the time to investigate this issue! Now it is time to raise the max_map_count and continue our fuzzing campaign...

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