I'm able to replicate this on a recent ASAN build as well.

Here's the failed DCHECK:

[1:1:1215/135714.641969:FATAL:Vector.h(373)] Check failed: new_capacity <= Allocator::template MaxElementCountInBackingStore<T>() (3000000171 vs. 2147479551)

Which is https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/wtf/Vector.h?q=MaxElementCountInBackingStore%3CT%3E&sq=package:chromium&l=370

Since it appears that this requires user action in DevTools to trigger (I have not been able to replicate in in-page JavaScript), I'm marking this Severity-Low for now.

I think this is fundamentally the same sort of issue as  Issue 740214 , making it a functional problem rather than a security issue. The JavaScript code attempts to allocate a gigabyte of memory and the tab crashes, likely due to memory exhaustion. The developer tools lose their connection to the dead render process.

If you visit chrome://crashes, can you share the "Uploaded Crash Report ID" from the crashing render process so we can verify?

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=5105937148018688.

Fixing my test case (to work in-page) corroborates that this appears to just be an OOM crash. I added it to clusterfuzz just to double check there.

Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

I would bet this is a simple OOM.

Not sure why JavaScript Array constructor hits Blink's Vector constructor, though.

Yeah, if this is just an OOM, then I'd comfortable marking it as functional bug rather than a security bug.

On a separate note, the console.log() version (from my clusterfuzz test case)  would point to crbug.com/772468 as one potential security consequence. But that seems like a more general concern than this specific OOM.

CF is hitting a FATAL:ipc_channel_proxy.cc(540)] Check failed: message->size() <= Channel::kMaximumMessageSize (2000000188 vs. 134217728) which would be a functional issue. Marking as such along the lines of the discussion.

I came up with one more exploit.

1. Open a new tab
2. Load this JS Fiddle page containing the exploit code https://jsfiddle.net/wmacx4zd/2/
3. Tab Crashed

Video POC of the exploit

Deleted: chrome_exploit_2.mp4 152 KB

	chrome_exploit_2.mp4 152 KB View Download

Javascript Code Written Inside JS Code Area in JSFiddle

var a = new Array(999999999);
console.log(a+1);
console.log(a+1);
console.log(a=a+1);
console.log(a=a+1);

Any update on this issue ?

Any update on this issue ?

Detailed report: https://clusterfuzz.com/testcase?key=5105937148018688

Job Type: linux_asan_chrome_mp
Crash Type: CHECK failure
Crash Address: 
Crash State:
  message->size() <= Channel::kMaximumMessageSize in ipc_channel_proxy.cc
  IPC::ChannelProxy::SendInternal
  IPC::SyncChannel::Send
  
Sanitizer: address (ASAN)

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5105937148018688

See https://github.com/google/clusterfuzz-tools for more information.

Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days we've been seeing this crash frequently. If you are unable to reproduce this, please try a speculative fix based on the crash stacktrace in the report. The fix can be verified by looking at the crash statistics in the report, a day after the fix is deployed. We will auto-close the bug if the crash is not seen for 14 days.

This issue can be reproduced in Version 69.0.3497.100 (Official Build) (64-bit) , Windows 10