This looks interesting...

This happens due to separate heap views being constructed without passing an actual underlying heap to the module. In that case JavaScript semantics would create separate heaps (i.e. ArrayBuffers) for each view, whereas WASM will still end up using one underlying heap.

IMHO such an instantiation should just raise a link-time error during module instantiation.

function Module(stdlib, foreign, heap) {
  "use asm";
  var a1 = new stdlib.Int16Array(heap);
  var a2 = new stdlib.Int32Array(heap);
  function f() {
    a1[0] = 0x12341234;
    return a2[0] | 0;
  }
  return { f:f };
}
var m = Module(this);
print(m.f());

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/3a9e4d801867604d1447be77ecad0e13dccc6f72

commit 3a9e4d801867604d1447be77ecad0e13dccc6f72
Author: Michael Starzinger <mstarzinger@chromium.org>
Date: Thu Apr 27 10:45:37 2017

[asm.js] Cleanup asm.js instantiation API.

This refactors the {AsmJs} methods used for instantiating an asm.js
module to only use one single entry point. It is in preparation to
validate the "memory" argument as well.

R=clemensh@chromium.org
BUG= chromium:715505 

Change-Id: I5e26fcf46f98c053080c70b26c0f562afc7f794a
Reviewed-on: https://chromium-review.googlesource.com/488226
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44922}
[modify] https://crrev.com/3a9e4d801867604d1447be77ecad0e13dccc6f72/src/asmjs/asm-js.cc
[modify] https://crrev.com/3a9e4d801867604d1447be77ecad0e13dccc6f72/src/asmjs/asm-js.h
[modify] https://crrev.com/3a9e4d801867604d1447be77ecad0e13dccc6f72/src/runtime/runtime-compiler.cc

 Issue 681088  has been merged into this issue.

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

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

No ClusterFuzz, you are wrong and you should feel bad. :)

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/f6296b344e771e59b80a10f84f30e7a757823bf5

commit f6296b344e771e59b80a10f84f30e7a757823bf5
Author: Michael Starzinger <mstarzinger@chromium.org>
Date: Thu Apr 27 14:47:03 2017

[asm.js] Fix heap buffer checking during instantiation.

This makes sure that asm.js modules can only be instantiated with a
valid {ArrayBuffer} as the underlying heap buffer for all cases where
accepting anything else would be observably different from JavaScript
proper.

R=clemensh@chromium.org
TEST=mjsunit/asm/asm-memory
BUG= chromium:715505 , chromium:715748 

Change-Id: I355686200151c5667bf836824de922d657a8d943
Reviewed-on: https://chromium-review.googlesource.com/488521
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44938}
[modify] https://crrev.com/f6296b344e771e59b80a10f84f30e7a757823bf5/src/asmjs/asm-js.cc
[add] https://crrev.com/f6296b344e771e59b80a10f84f30e7a757823bf5/test/mjsunit/asm/asm-memory.js
[modify] https://crrev.com/f6296b344e771e59b80a10f84f30e7a757823bf5/test/mjsunit/wasm/asm-wasm.js

ClusterFuzz has detected this issue as fixed in range 44937:44938.

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

Fuzzer: foozzie_js_mutation
Job Type: v8_foozzie
Platform Id: linux

Crash Type: V8 correctness failure
Crash Address: 
Crash State:
  configs: x64,ignition:x64,ignition_asm
  sources: d05
  
Sanitizer: address (ASAN)

Regressed: V8: 44685:44686
Fixed: V8: 44937:44938

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


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.

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.