This issue looks similar to  bug 784196 , hence assigning to @rockot for more updates.

Thanks!

Looks like BlobRegistry.Register can be oversized. I guess we could have some safe limits enforced? At some point it's probably OK to let a renderer crash if it tries to do something stupid like construct a blob with 100 million data elements, no?

Hah, in this case it seems it isn't the data elements that are oversized (and you'd have to jump through quite a few hoops to actually get that to be oversized, since we do cap the amount of embedded data in the data elements), but instead it's the mime-type of the created blob that is ~150 MiB. It does seem reasonable to indeed put a limit on that as well.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5be4d4f31e331f16da17c3e64a73474452ea91ad

commit 5be4d4f31e331f16da17c3e64a73474452ea91ad
Author: Marijn Kruisselbrink <mek@chromium.org>
Date: Tue Apr 24 19:15:53 2018

[FileAPI] Put a (pretty arbitrary) cap on the size of a blob mimetype.

Unbounded mime-types result in the renderer getting killed because it is
trying to send a too large mojo message. Sensible mimetypes shouldn't be
very large anyway, so arbitrarily capping the mimetype at 64K is a
reasonable work around.

Bug:  835753 
Change-Id: Idf91a27976f41b8cc07662a82f33d45a355c14f8
Reviewed-on: https://chromium-review.googlesource.com/1026201
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: Daniel Murphy <dmurph@chromium.org>
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553225}
[modify] https://crrev.com/5be4d4f31e331f16da17c3e64a73474452ea91ad/third_party/blink/renderer/core/fileapi/blob.cc

ClusterFuzz has detected this issue as fixed in range 553222:553241.

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

Fuzzer: inferno_twister
Job Type: mac_asan_chrome
Platform Id: mac

Crash Type: CHECK failure
Crash Address: 
Crash State:
  message->data_num_bytes() < GetConfiguration().max_message_num_bytes in node_cha
  mojo::edk::NodeChannel::WriteChannelMessage
  mojo::edk::NodeChannel::SendChannelMessage
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=511876:511938
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=553222:553241

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

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

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

ClusterFuzz testcase 5755250246680576 is verified as fixed, so closing issue as verified.

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