I've been able to repro the out-of-bounds in Chrome.
However, it seems to occur both with optimized code AND with the interpreter, which seems to suggest it's a legit out of bounds failure.
Seeing what it does with OOB turned off.
(Also able to repro that it doesn't get the exception in FF).

Without the OOB checks it actually crashes.

Interesting! Before reporting this bug, I tried compiling with asm.js and using emscripten's "-s SAFE_HEAP=1" flag which throws errors for OOB memory accesses. But I didn't get any errors when I ran the same test case with that build so that made me more confident that it's not our code. It could still be possible that we somehow have a bug in our WebAssembly build and not in our asm.js build, and that the bug only appears in Chrome, but I'm not sure how to tell since the SAFE_HEAP flag doesn't work with WebAssembly. Can you think of another way to verify where the problem is?

emscripten's SAFE_HEAP should work identically in wasm as in asm.js, when compiling with typical flags. Perhaps you're using something it's not compatible with in wasm somehow, how are you building?

I was going off https://github.com/kripken/emscripten/issues/4474, which seemed to indicate that it doesn't work to me. Glad to hear I was wrong! I'll gave it a shot but it didn't work. Here's the issue I logged: https://github.com/kripken/emscripten/issues/5285.

Also: when I was looking through tickets for SAFE_HEAP I found https://github.com/kripken/emscripten/issues/5161 which sounds like the problem we're experiencing too.

We tried using the SAFE_HEAP option but it didn't detect anything wrong with our app (details are in the comments of the bugs linked above). The ASSERTIONS option did reveal something interesting though. The only apparent difference between the execution trace in Firefox and Chrome is that Firefox is able to grow the heap from 1gb to 1.25gb while Chrome fails to do this. The specific error is this:

"Module.reallocBuffer: Attempted to grow from 1073741824 bytes to 1342177280 bytes, but got error: RangeError: WebAssembly.Memory.grow(): maximum memory size exceeded"

Can you think of a reason why Chrome would fail to grow the memory past 1gb? Is this a limitation of Chrome's WebAssembly implementation? This is in a 64-bit browser on a machine with 16gb of RAM. There is no "maximum" property passed to the WebAssembly.Memory constructor, just the "initial" property. I tried adding a "maximum" value of 2gb/page_size to that constructor parameter but Chrome still had the same problem (failing to grow from 1gb to 1.25gb).

I found this in the V8 source code:

"constexpr size_t kV8MaxWasmMemoryPages = 16384;  // = 1 GiB"

Maybe that's the reason? Here's the link: https://github.com/v8/v8/blob/54be464fe4a4f154aa27f4382cf9641c085192af/src/wasm/wasm-limits.h#L25

This does indeed seem to be from the 1GB cap.
We had already been working on lifting that (but just filed the bug today).
Fix coming soon from gdeepti.

A little more context - this is a combination of two issues, the 1GB cap, as well as the garbage collector freeing externalized memory. The ordering of OOB/crash can vary based on when garbage collection is triggered. We've root caused the second issue as well, fix coming soon from eholk@. 

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

commit 7e6ed62071d2756688a23bd6dac096b0d4660b5d
Author: gdeepti <gdeepti@chromium.org>
Date: Wed Jun 14 00:55:24 2017

[wasm] Increase WebAssembly.Memory maximum size to 2GB

BUG= v8:6478 ,  chromium:729768 

R=bradnelson@chromium.org, eholk@chromium.org

Review-Url: https://codereview.chromium.org/2903153002
Cr-Commit-Position: refs/heads/master@{#45931}

[modify] https://crrev.com/7e6ed62071d2756688a23bd6dac096b0d4660b5d/src/compiler/wasm-compiler.cc
[modify] https://crrev.com/7e6ed62071d2756688a23bd6dac096b0d4660b5d/src/wasm/wasm-limits.h
[modify] https://crrev.com/7e6ed62071d2756688a23bd6dac096b0d4660b5d/test/mjsunit/mjsunit.status
[modify] https://crrev.com/7e6ed62071d2756688a23bd6dac096b0d4660b5d/test/mjsunit/wasm/grow-memory.js
[modify] https://crrev.com/7e6ed62071d2756688a23bd6dac096b0d4660b5d/test/mjsunit/wasm/import-memory.js
[add] https://crrev.com/7e6ed62071d2756688a23bd6dac096b0d4660b5d/test/mjsunit/wasm/large-offset.js

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

commit 21ee6d8f8b051448703a0bc12b5fb39573257f43
Author: machenbach <machenbach@chromium.org>
Date: Wed Jun 14 06:39:46 2017

Revert of [wasm] Increase WebAssembly.Memory maximum size to ~2GB (patchset #10 id:200001 of https://codereview.chromium.org/2903153002/ )

Reason for revert:
gc stress failure:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/11122

Original issue's description:
> [wasm] Increase WebAssembly.Memory maximum size to 2GB
>
> BUG= v8:6478 ,  chromium:729768 
>
> R=bradnelson@chromium.org, eholk@chromium.org
>
> Review-Url: https://codereview.chromium.org/2903153002
> Cr-Commit-Position: refs/heads/master@{#45931}
> Committed: https://chromium.googlesource.com/v8/v8/+/7e6ed62071d2756688a23bd6dac096b0d4660b5d

TBR=bradnelson@chromium.org,eholk@chromium.org,gdeepti@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= v8:6478 ,  chromium:729768 

Review-Url: https://codereview.chromium.org/2935243002
Cr-Commit-Position: refs/heads/master@{#45932}

[modify] https://crrev.com/21ee6d8f8b051448703a0bc12b5fb39573257f43/src/compiler/wasm-compiler.cc
[modify] https://crrev.com/21ee6d8f8b051448703a0bc12b5fb39573257f43/src/wasm/wasm-limits.h
[modify] https://crrev.com/21ee6d8f8b051448703a0bc12b5fb39573257f43/test/mjsunit/mjsunit.status
[modify] https://crrev.com/21ee6d8f8b051448703a0bc12b5fb39573257f43/test/mjsunit/wasm/grow-memory.js
[modify] https://crrev.com/21ee6d8f8b051448703a0bc12b5fb39573257f43/test/mjsunit/wasm/import-memory.js
[delete] https://crrev.com/7e6ed62071d2756688a23bd6dac096b0d4660b5d/test/mjsunit/wasm/large-offset.js

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

commit 1ff3e7ea3352e3ee4baf8851cfe80129cc5fa8e6
Author: gdeepti <gdeepti@chromium.org>
Date: Fri Jun 16 03:35:09 2017

[wasm] Increase WebAssembly.Memory maximum size to 2GB

BUG= v8:6478 ,  chromium:729768 

R=bradnelson@chromium.org, eholk@chromium.org

Review-Url: https://codereview.chromium.org/2903153002
Cr-Original-Commit-Position: refs/heads/master@{#45931}
Committed: https://chromium.googlesource.com/v8/v8/+/7e6ed62071d2756688a23bd6dac096b0d4660b5d
Review-Url: https://codereview.chromium.org/2903153002
Cr-Commit-Position: refs/heads/master@{#45967}

[modify] https://crrev.com/1ff3e7ea3352e3ee4baf8851cfe80129cc5fa8e6/src/assembler.cc
[modify] https://crrev.com/1ff3e7ea3352e3ee4baf8851cfe80129cc5fa8e6/src/compiler/wasm-compiler.cc
[modify] https://crrev.com/1ff3e7ea3352e3ee4baf8851cfe80129cc5fa8e6/src/wasm/wasm-limits.h
[modify] https://crrev.com/1ff3e7ea3352e3ee4baf8851cfe80129cc5fa8e6/test/mjsunit/wasm/grow-memory.js
[modify] https://crrev.com/1ff3e7ea3352e3ee4baf8851cfe80129cc5fa8e6/test/mjsunit/wasm/import-memory.js
[add] https://crrev.com/1ff3e7ea3352e3ee4baf8851cfe80129cc5fa8e6/test/mjsunit/wasm/large-offset.js

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

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

bradnelson: 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

bradnelson@: Can this bug be marked as fixed now?
- you friendly secondary security sheriff

bradnelson: Uh oh! This issue still open and hasn't been updated in the last 28 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

Are we expecting any more fixes to land for this?

Yes, it appears there is still a limitation (up to 32767 pages). More compiler work in V8 is required to make this work.

A friendly reminder that M61 branch is coming soon on 07/20! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix ASAP to trunk. This way we branch M61 from a high quality trunk. Thank you.

URGENT - PTAL.
Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the M61 branch #3163 ASAP to have enough baking time in Beta before Stable promotion. Thank you!

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label.

I was under the impression that this was fixed. What more needs to be done?

Removing security labels, as this is just an implementation-defined limit on memory size, and no OOB access occurs.

c#28

I've filed 749511 for this, since the limitation to 2GiB is also due to Blink.

Don't all the browsers have a 2GiB limit right now? This bug is about a case where we where giving an OOM but the other browsers were not. Now that the limit has been raised from 1GiB to 2GiB, I think we should call this issue fixed, especially since it was marked as a release blocker.

I agree that we should raise the limit to 4GiB, but that seems like a longer term change.

c#31, I agree that this is a longer term issue (thus the separate bug).

eholk@ - trying to assess the security implications: does the reported "memory access out of bounds" mean that a webasm program could potentially access memory it's not supposed to have access to?

awhalley@ - No, this is basically the same as accessing an out of bounds element on an ArrayBuffer or regular Array. The fact that we're seeing the error message means we caught it. This is the expected behavior when a Wasm program tries to reach outside its allocated memory.