afl win, lets see if libfuzzer finds this.

libFuzzer might be crippled by an input that consumes 10 seconds and uses 1.4Gb RAM, input attached. Shall we file a separate bug, or CF can do it? 

We already know that in presence of sloooow inputs and OOMs libFuzzer (in-process) has a disadvantage over AFL (partial out-of-process). 

Deleted: slow-unit-93d85f083198d5d4214545111d9f0c38e6a34563 26 bytes

slow-unit-93d85f083198d5d4214545111d9f0c38e6a34563 26 bytes View Download

Another problem with this target is that it accumulates memory,
there is some high-level leak or something. 

/usr/bin/time ./out/libfuzzer/v8_wasm_code_fuzzer 0cc13ac0b992d2aa32a4e04c89936ce539d97646 -runs=1 -rss_limit_mb=30000

2244580 maxresident

/usr/bin/time ./out/libfuzzer/v8_wasm_code_fuzzer 0cc13ac0b992d2aa32a4e04c89936ce539d97646 -runs=10 -rss_limit_mb=30000

9366176 maxresident

9Gb after 10 runs is not going to work well with libFuzzer (or any other in-process fuzzer)

Before going completely into OOM, libFuzzer has found a couple of assertion failures; 
# Fatal error in ../../v8/src/assembler.cc, line 360
# Check failed: old_size == 0 || wasm_memory_size_reference() <= old_size.

# Fatal error in ../../v8/src/compiler/scheduler.cc, line 1281
# Check failed: InsideSameDominatorChain(block, data->minimum_block_).

Deleted: 0cc13ac0b992d2aa32a4e04c89936ce539d97646 57 bytes

0cc13ac0b992d2aa32a4e04c89936ce539d97646 57 bytes View Download

I wonder if the memories allocated to the various modules are not being cleaned up properly. This may happen, e.g. because the actual GC'able JSArrayBuffer is very small, but the memory it holds onto (malloc'd) is very large. So the GC heap does not fill up, but the malloc'd memory does. Maybe we should explicitly "neuter" or deallocate the WASM memories after each CF run.

I've checked logs from CF runs - libfuzzer always dies due to memory leaks. When I run it locally with disabled leak detection, it always goes Out-Of-Memory.

Link to all crashes: https://cluster-fuzz.appspot.com/crashstats?fuzzer_name=libfuzzer_v8_wasm_code_fuzzer&job_type=All&security_flag=Both&date_start=2016-08-01&date_end=2016-10-01


Both leak and OOM have been detected, I'll file them separately.

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

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/+/79e685e277298102c0386c8da0b5c2e8316baca2

commit 79e685e277298102c0386c8da0b5c2e8316baca2
Author: ahaas <ahaas@chromium.org>
Date: Thu Sep 01 14:05:19 2016

[wasm] Validate the index of set local in AnalyzeLoopAssignment

BUG= chromium:642867 
R=titzer@chromium.org
TEST=loop-assignment-analysis-unittest.cc:regress_642867

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

[modify] https://crrev.com/79e685e277298102c0386c8da0b5c2e8316baca2/src/wasm/ast-decoder.cc
[modify] https://crrev.com/79e685e277298102c0386c8da0b5c2e8316baca2/test/unittests/wasm/loop-assignment-analysis-unittest.cc

ClusterFuzz has detected this issue as fixed in range 416010:416188.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=6192829586210816

Fuzzer: afl_v8_wasm_code_fuzzer
Job Type: afl_chrome_asan
Platform Id: linux

Crash Type: UNKNOWN WRITE
Crash Address: 0x624ffc032190
Crash State:
  v8::internal::wasm::WasmFullDecoder::AnalyzeLoopAssignment
  v8::internal::wasm::WasmFullDecoder::PrepareForLoop
  v8::internal::wasm::WasmFullDecoder::DecodeFunctionBody
  
Recommended Security Severity: High

Regressed: https://cluster-fuzz.appspot.com/revisions?job=afl_chrome_asan&range=415614:415641
Fixed: https://cluster-fuzz.appspot.com/revisions?job=afl_chrome_asan&range=416010:416188

Minimized Testcase (0.02 Kb): https://cluster-fuzz.appspot.com/download/AMIfv96DeykxBjuaIaowDnFaUty91phfbWn02bAbyYpPEOO3mdx4lXvh6T4Z0hDbegTroN1JpDkYvFApyPyKLfLmopZuB59dx7O5sjPnwEbEK_96hDCtS0RG7mFdR-CuK8TSmAxucaS2DrjJIKwsvCIQamOPcaY7Bw?testcase_id=6192829586210816

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.

ClusterFuzz testcase is verified as fixed, closing issue.

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