regression from
https://chromium.googlesource.com/v8/v8/+log/49106e48585335965b5d7861664df0a4a20a7ca7..71655f47a078d72573d4bf21226176e085d31fb6?pretty=fuller&n=10000

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

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

commit 025e3ab1e58e571c5eed1f7fe2104009894d572d
Author: Eric Holk <eholk@chromium.org>
Date: Sat Sep 30 01:07:08 2017

[wasm] set thread-in-wasm flag after converting arguments

In JS to Wasm wrappers, arguments have to be converted from JavaScript's
representation to Wasm's representation. Because of property accessors, this can
result in JavaScript or even asm.js/Wasm code being run. We were previously
setting this flag before doing the parameter conversions, and if these
conversions triggered a Wasm property getter then we would try to set the flag
twice.

With this change, we wait until after all argument conversions are done to set
the flag.

Bug:  chromium:769846 

R=bradnelson@chromium.org

Change-Id: Ia4b56df45619dcad69f3750bb33cacfedcaeb5b2
Reviewed-on: https://chromium-review.googlesource.com/693414
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48244}
[modify] https://crrev.com/025e3ab1e58e571c5eed1f7fe2104009894d572d/src/compiler/wasm-compiler.cc
[modify] https://crrev.com/025e3ab1e58e571c5eed1f7fe2104009894d572d/src/compiler/wasm-compiler.h
[add] https://crrev.com/025e3ab1e58e571c5eed1f7fe2104009894d572d/test/mjsunit/regress/wasm/regression-769846.js

ClusterFuzz has detected this issue as fixed in range 48243:48244.

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

Fuzzer: mbarbella_js_mutation
Job Type: linux_asan_d8_dbg
Platform Id: linux

Crash Type: DCHECK failure
Crash Address: 
Crash State:
  !IsThreadInWasm() in trap-handler.h
  SetThreadInWasm
  __RT_impl_Runtime_SetThreadInWasm
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_d8_dbg&range=48148:48149
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_d8_dbg&range=48243:48244

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

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 5229524169261056 is verified as fixed, so closing issue as verified.

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

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