The trouble is at this line (wasm-compile.cc:61) https://cs.chromium.org/chromium/src/v8/test/fuzzer/wasm-compile.cc?q=wasm-compile.cc+package:%5Echromium$&l=61

it should be "T result = T();"

But, looking closer - what's the intent on line 62? say that I'm get<uint32_t> -ing, and I only have 1 byte available. Line 62 would read it in LSB on little endian architectures, or HSB on big endian machines.

What's the intended behavior? And why do we need to support size() < sizeof<T>?

I think the memcpy is just to avoid an unaligned memory access. 

Assigning eholk@ to take a look.

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

Fwiw, not convinced this is pri-1, nor a security issue. The uninitialized variable is in fuzzer code, i.e. not production code, from what I see.

The fix for this should be a one liner, so I will get a CL out soon.

I agree with Mircea that this uninitialized variable is only in fuzzer code, which only runs in test environments, so it's not as big of an issue as if it were in production code.

The memcpy is there to support smaller than sizeof(T) values, not because of alignment. The idea behind this fuzzer is that it recursively splits the input data from the fuzzing harness into smaller pieces to build up an expression. Once we get below sizeof(T), we emit a constant instead of an expression. Originally I had it just return 0 if there wasn't enough data left, but for constants I think there is still value in using whatever data is available even if it's not the full sizeof(T).

I see, so for smaller-than sizeof(T), we just want the data regardless of its value (so, endian-ness is irrelevant). Is that correct?

Could you add a comment there about it, also perhaps motivating why we want the data regardless of its value?

Fix sent out for review: https://chromium-review.googlesource.com/c/448317/

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

commit d6808c0f9cdca496b11a397da91f2f5b360185e6
Author: Eric Holk <eholk@chromium.org>
Date: Wed Mar 01 17:33:29 2017

[wasm] compile fuzzer: initialize temporary before filling.

BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=697191

Change-Id: I01ddd6824b1a79d86944ac766f5c2070e9b0c244
Reviewed-on: https://chromium-review.googlesource.com/448317
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43522}
[modify] https://crrev.com/d6808c0f9cdca496b11a397da91f2f5b360185e6/test/fuzzer/wasm-compile.cc

ClusterFuzz has detected this issue as fixed in range 454045:454092.

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

Fuzzer: libfuzzer_v8_wasm_compile_fuzzer
Job Type: libfuzzer_chrome_msan
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  v8::internal::wasm::LEBHelper::write_i32v
  v8::internal::wasm::WasmFunctionBuilder::EmitVarInt
  v8::internal::wasm::WasmFunctionBuilder::EmitWithVarInt
  
Sanitizer: memory (MSAN)

Recommended Security Severity: Medium

Regressed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_msan&range=453545:453564
Fixed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_msan&range=454045:454092

Reproducer Testcase: https://cluster-fuzz.appspot.com/download/AMIfv94wFlUXaJFonAyygcmtJip_XFVyfFrMqVomPJYDUWbCITT8sqhEb0WQhKUtaD2e3acPpKguja2sp2C-x9Gp_qCsiaclkXSt8kSctkzCqs_pX3nM85JUpmaaD8Rw71BdSbYKQxGEuNQ3BedUOt6cti_-N-En68wgSsdD9rsp_DMWS1PpP3kIffWTCRQ4ekXfkzOf9s5YcNsGY1dEcV8NlQpYiOGxHFYwRiDws8iHlZDM6qQWVFZMLxRJEdet47vz-1VRHwkHYURlrnVwjAVu-nfNGm0eYJnYrGACgnyiQylwv5-N3P6sqm74poI0I7pEoru1pe1tBJnI2MU8as6x0Ok9SeoPqbW5TBzzBKtoPLKQzncPIJc?testcase_id=5514811648770048


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

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

 Issue 698502  has been merged into this issue.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), bhthompson@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please merge your change to M58 branch 3029 before 5:00 PM PT, Monday (03/13/17) so we can take it in for next week dev release. Thank you!

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

commit 6dda5f61a5555500f7c090e7cdc11e3b8d2fcec4
Author: ishell@chromium.org <ishell@chromium.org>
Date: Mon Mar 13 08:30:03 2017

Merged: [wasm] compile fuzzer: initialize temporary before filling.

Revision: d6808c0f9cdca496b11a397da91f2f5b360185e6

BUG=https://bugs.chromium.org/p/chromium/issues/detail?id=697191
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2746063002 .
Cr-Commit-Position: refs/branch-heads/5.8@{#23}
Cr-Branched-From: eda659cc5e307f20ac1ad542ba12ab32eaf4c7ef-refs/heads/5.8.283@{#1}
Cr-Branched-From: 4310cd02d2160b1457baed81a2f40063eb264a21-refs/heads/master@{#43429}

[modify] https://crrev.com/6dda5f61a5555500f7c090e7cdc11e3b8d2fcec4/test/fuzzer/wasm-compile.cc

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