Predator and CL did not provide any possible suspects.
Using Code Search for the file, "wasm-compile.cc" assigning to the concern owner.

Suspecting Commit#
https://chromium.googlesource.com/v8/v8.git/+/d6808c0f9cdca496b11a397da91f2f5b360185e6

@eholk -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

I ran the test case found by Clusterfuzz locally and I got a failure, although it was a different one. The Wasm interpreter and the Wasm compiler disagreed on the behavior of the program.

It looks like the problem is that the MachineGraphReducer is incorrectly sign extending a value. I am working on a fix now.

I have a fix out for review here: https://chromium-review.googlesource.com/c/482448/

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

commit ec772a4fd8b6e9a79506328787218459b733606c
Author: Eric Holk <eholk@chromium.org>
Date: Thu Apr 20 21:03:31 2017

Restrict range for int64_t to immediate conversions

The included test case illustrates the problem. It subtracts (16 << 27)
from another number. The Machine Operator Reducer would replace the
shift computation with 0x0000000080000000, and then change the subtract
to an add of -(0x0000000080000000), which is 0xffffffff80000000.
The instruction selector would determine that this value could be an
immediate, because it fits in 32 bits, so it would select the lea
instruction. Finally, the code generator would detect that the
immediate was less than 0, flip the sign and replace the add with a
subtract of 0x80000000. Because the x64 subtract instruction's
immediate field is 32 bits, the processor would interpret this as
0xffffffff80000000 instead of an unsigned value.

This change fixes the issue by making the CanBeImmediate check
explicitly compare against INT_MIN and INT_MAX. We disallow INT_MIN
as an immediate precisely because we cannot tell 0x0000000080000000
from 0xffffffff80000000 when truncated to 32 bits.

Bug:  chromium:711203 
Change-Id: Ie371b8ea290684a6bb723bae9c693a866f961850
Reviewed-on: https://chromium-review.googlesource.com/482448
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44758}
[modify] https://crrev.com/ec772a4fd8b6e9a79506328787218459b733606c/src/compiler/graph-reducer.cc
[modify] https://crrev.com/ec772a4fd8b6e9a79506328787218459b733606c/src/compiler/x64/instruction-selector-x64.cc
[add] https://crrev.com/ec772a4fd8b6e9a79506328787218459b733606c/test/mjsunit/regress/wasm/regression-711203.js

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

commit ec772a4fd8b6e9a79506328787218459b733606c
Author: Eric Holk <eholk@chromium.org>
Date: Thu Apr 20 21:03:31 2017

Restrict range for int64_t to immediate conversions

The included test case illustrates the problem. It subtracts (16 << 27)
from another number. The Machine Operator Reducer would replace the
shift computation with 0x0000000080000000, and then change the subtract
to an add of -(0x0000000080000000), which is 0xffffffff80000000.
The instruction selector would determine that this value could be an
immediate, because it fits in 32 bits, so it would select the lea
instruction. Finally, the code generator would detect that the
immediate was less than 0, flip the sign and replace the add with a
subtract of 0x80000000. Because the x64 subtract instruction's
immediate field is 32 bits, the processor would interpret this as
0xffffffff80000000 instead of an unsigned value.

This change fixes the issue by making the CanBeImmediate check
explicitly compare against INT_MIN and INT_MAX. We disallow INT_MIN
as an immediate precisely because we cannot tell 0x0000000080000000
from 0xffffffff80000000 when truncated to 32 bits.

Bug:  chromium:711203 
Change-Id: Ie371b8ea290684a6bb723bae9c693a866f961850
Reviewed-on: https://chromium-review.googlesource.com/482448
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44758}
[modify] https://crrev.com/ec772a4fd8b6e9a79506328787218459b733606c/src/compiler/graph-reducer.cc
[modify] https://crrev.com/ec772a4fd8b6e9a79506328787218459b733606c/src/compiler/x64/instruction-selector-x64.cc
[add] https://crrev.com/ec772a4fd8b6e9a79506328787218459b733606c/test/mjsunit/regress/wasm/regression-711203.js

ClusterFuzz has detected this issue as fixed in range 465919:466809.

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

Fuzzer: libfuzzer_v8_wasm_compile_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  Disposing the isolate that is entered by a thread in wasm-compile.cc
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=455109:455254
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=465919:466809

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


See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.