Reproducer:
  var __v_6 = [];
  var __v_11 = % WasmNumInterpretedCalls(__v_6);

Runtime_WasmNumInterpretedCalls checks that the first argument is a wasm instance object.
Will have to figure out what to do about this.

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

Fuzzer: inferno_js_fuzzer
Job Type: linux_asan_d8
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  WasmInstanceObject::IsWasmInstanceObject(*instance_obj) in runtime-test.cc
  
Sanitizer: address (ASAN)

Regressed: V8: 43854:43855

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


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

+mstarzinger

It looks like runtime functions that are being used in tests (e.g. OptimizeFunctionOnNextCall) don't CHECK their argument types, but just return undefined if illegal types are passed.
Is this also the right thing to do here? Or better throw a TypeError?

+mstarzinger

Please see comment/question on previous comment. Can certainly wait until Monday :)

Lowering priority, since this requires --allow-natives-syntax.

Proposed fix: https://chromium-review.googlesource.com/509509

Nah, we shouldn't try to harden arbitrary runtime functions unless we explicitly want to fuzz them. The problem here is that "mjsunit" contains files that have the "% FooBar()" patterd and ClusterFuzz picks them up and defeats it's own black list. The correct fix is to fix the affected test cases in the corpus, in this case:

- test/mjsunit/wasm/interpreter-mixed.js
- test/mjsunit/wasm/interpreter.js

Happy to discuss on Monday.

Similar previous occurrences:

https://chromium-review.googlesource.com/447398
https://codereview.chromium.org/2682203003

Oh, I see. It's clang-format who reformats "%FooBar()" to "% FooBar()". That's unfortunate.

Will create the right fix on Monday then.

Yeah, that's because the "natives syntax" is a V8 hand-made feature and not JavaScript proper. It trips up clang-format grammar rules. Also it actually breaks semicolon insertion (if the previous line before the runtime call is not ended wirh a semicolon, then V8's parser will not recognize the call and think it is a modulus operation).

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

commit a4eb80f7a6782838bbeec0fa49a74d83bddef7cd
Author: Clemens Hammacher <clemensh@chromium.org>
Date: Tue May 23 09:26:56 2017

[wasm] Fix runtime call syntax

This is to avoid ClusterFuzz picking up and using those calls.
With the proper syntax (no whitespace), they are recognized as runtime
calls and will be checked against a whitelist.

R=mstarzinger@chromium.org
BUG= chromium:724459 

Change-Id: I5533f066feeb66f622230b12f79f9d227e2b2465
Reviewed-on: https://chromium-review.googlesource.com/509575
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45475}
[modify] https://crrev.com/a4eb80f7a6782838bbeec0fa49a74d83bddef7cd/test/mjsunit/wasm/interpreter-mixed.js
[modify] https://crrev.com/a4eb80f7a6782838bbeec0fa49a74d83bddef7cd/test/mjsunit/wasm/interpreter.js

The CL addresses the issue by avoiding clusterfuzz picking up the disallowed runtime call.

 Issue 725440  has been merged into this issue.

ClusterFuzz has detected this issue as fixed in range 46474:46475.

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

Fuzzer: inferno_js_fuzzer
Job Type: linux_asan_d8
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  WasmInstanceObject::IsWasmInstanceObject(*instance_obj) in runtime-test.cc
  
Sanitizer: address (ASAN)

Regressed: V8: 43854:43855
Fixed: V8: 46474:46475

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


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.

ClusterFuzz testcase 5615411944226816 is still reproducing on tip-of-tree build (trunk).

Please re-test your fix against this testcase and if the fix was incorrect or incomplete, please re-open the bug. Otherwise, ignore this notification and add ClusterFuzz-Wrong label.

The test case still reproduces, but was invalid from the beginning.
The fix was to avoid generating such tests in the future.

 Issue 754963  has been merged into this issue.

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