The awesome fuzzer found over the weekend the bug we were discussing last week:
If one instance imports a function of another instance, and that other instance dies, this can cause problems.

Reproducer:
===================================================================
load('test/mjsunit/wasm/wasm-constants.js');
load('test/mjsunit/wasm/wasm-module-builder.js');

builder1 = new WasmModuleBuilder();
builder1.addFunction('exp1', kSig_v_v).addBody([kExprUnreachable]).exportFunc();

builder2 = new WasmModuleBuilder();
builder2.addImport('imp', 'imp', kSig_v_v);
builder2.addFunction('call_imp', kSig_v_v)
    .addBody([kExprCallFunction, 0])
    .exportFunc();

export1 = builder1.instantiate().exports.exp1;
export2 = builder2.instantiate({imp: {imp: export1}}).exports.call_imp;
export1 = undefined;

let a = [0];
for (i = 0; i < 1024; ++i) {
  a = a.concat(new Array(i).fill(i));
  assertThrows(() => export2(-1, -4), WebAssembly.RuntimeError);
  gc();
}
===================================================================

The above reproducer actually triggers the bug at another location (in WasmSharedModuleData::module()), where we do:
  return *(reinterpret_cast<wasm::WasmModule**>(                                 
      Foreign::cast(get(kModuleWrapper))->foreign_address()));                   
but the foreign_address is 0. I am still trying to find out who resets the foreign address.
Adding a second "gc()" call to the loop makes the error show up in the reported location.

Reproduces in our latest 5.9 and 6.0 branches (5.9.223 and 6.0.318).

+mtrofin for context on the CL:
https://chromium-review.googlesource.com/539738

Removing security labels since it's a CHECK failure

ClusterFuzz has detected this issue as fixed in range 481083:481106.

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

Fuzzer: inferno_js_fuzzer
Job Type: linux_ubsan_vptr_d8
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  (owning_instance) != nullptr in runtime-wasm.cc
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_d8&range=451342:451385
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_d8&range=481083:481106

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


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

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

I think merging this fix back to M59 or M60 is not needed.
Even though the issue exists for quite some time, we did not encounter it in the wild. Also, it crashes reliably by a CHECK failure.

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