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

I don't understand.

  bool WriteBool(bool value) {
    return WriteInt(value ? 1 : 0);
  }

calls WriteInt() with 1 or 0 literal.

  bool WriteInt(int value) {
    return WritePOD(value);
  }

...

  // Writes a POD by copying its bytes.
  template <typename T> bool WritePOD(const T& data) {
    WriteBytesStatic<sizeof(data)>(&data);
    return true;
  }

...

template <size_t length> void Pickle::WriteBytesStatic(const void* data) {
  WriteBytesCommon(data, length);
}

...

inline void Pickle::WriteBytesCommon(const void* data, size_t length) {
  DCHECK_NE(kCapacityReadOnly, capacity_after_header_)
      << "oops: pickle is readonly";
  MSAN_CHECK_MEM_IS_INITIALIZED(data, length);
  void* write = ClaimUninitializedBytesInternal(length);
  memcpy(write, data, length);
}
...

// Check a memory region for initializedness, as if it was being used here.
// If any bits are uninitialized, crash with an MSan report.
// Use this to sanitize data which MSan won't be able to track, e.g. before
// passing data to another process via shared memory.
#define MSAN_CHECK_MEM_IS_INITIALIZED(p, size) \
    __msan_check_mem_is_initialized(p, size)


----------------------------

rockot@, you've added that sometime ago (https://codereview.chromium.org/1524613002). Would you mind taking a look?

FYI it is not sufficient to look at the top of the stack for uninitialized reads. In this case as you point out the WriteBool method (and everything within it) is trivially correct.

Looking a bit further down the stack it looks like the uninitialized bytes are coming from a bool field in StreamControls.

Digging a little further, I suspect https://codereview.chromium.org/2291893002. This introduces |disable_local_echo| in MediaStreamRequest. This field is never initialized, and is in some cases copied into a StreamControls field.

In progress now. Should be a simple fix. 

Does not affect the real workflow, as we never really use the value in case that it is uninitialized.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7098f1cafa2dc58dd43856c413987a5c25fa54fc

commit 7098f1cafa2dc58dd43856c413987a5c25fa54fc
Author: qiangchen <qiangchen@chromium.org>
Date: Fri Oct 14 16:55:20 2016

Bug Fix: Initialize |disable_local_echo|

This CL fixes the cause to a memory test failure. We did not initialize a field
of StreamControls.

BUG= 655973 

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

[modify] https://crrev.com/7098f1cafa2dc58dd43856c413987a5c25fa54fc/content/common/media/media_stream_options.cc

ClusterFuzz has detected this issue as fixed in range 425322:425380.

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

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_msan_chrome
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  void base::Pickle::WriteBytesStatic<4ul>
  IPC::ParamTraits<content::StreamControls>::Write
  IPC::MessageT<MediaStreamHostMsg_GenerateStream_Meta, std::__1::tuple<int, int, 
  
Recommended Security Severity: Medium

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_msan_chrome&range=425143:425240
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_msan_chrome&range=425322:425380

Minimized Testcase (0.38 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv94h2xC2F3ozuVR-8pmFH0dupvlicyqB9xtie9fBgsf8WJGqyrKC1FnE6Z0Kj18QoFavOCSKNjQQRzHYlI6B9Av9jUTagLrsleBkHc91Aits2nbToyvfF4tI3XYXV7ME09r6ryPYiFCDkN5ufVekd98FpN_QqA?testcase_id=5356921144213504
        <script src="./resources/promise-utils.js"></script>
        <script>
            function testCreateOfferOrAnswer() {
                return new Promise(function (resolve) {
                    navigator.mediaDevices.getUserMedia({ "video": true })
                })
            }
            testCreateOfferOrAnswer()
            .then(function () {
            })
</script>


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

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

Thanks rockot@ for helping to triage and qiangchen@ for the fix.

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