Why is this tagged low ? this looks like a stale object, that is used later. MSAN reports should be minimum medium severity, but this one might be high too.

By default we mark all use-of-uninitialized-value reports as Low severity. I think we do this because usually those values are simply some random bytes from memory and they don't lead to code execution or something dangerous. But if we consider that uninitialized value may be previously sprayed and deallocated + we have some object there (not an int), this is a good point to have Medium by default and High in some cases.

Are you talking about a default "recommended" severity rating for msan reports? We don't actually handle that automatically at the moment.

Should have a CL up in a bit.

I meant manually assigned severity so far. For "recommended" severity let's have Medium by default. Then we can manually drop or raise it depending on a type of object used. What do you think?

As far as general triage goes, we usually default them to medium unless we're sure that there's not an interesting way that the value can be read back (in which case they wouldn't be security bugs, or very rarely low in the case of limited info leaks). In cases like what Abhishek described, it is possible for these to be high.

Without taking the time to investigate, I'd rather lean towards the higher severity to be safe on this bug. In the case for MSan recommendations, I'm fine with medium being the default. It's pretty rare that they'd be high, though we should be careful when triaging these to make sure we're at least taking a quick look.

It appears to be an uninitialised pointer, so High seems quite reasonable here.

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium.git/+/0f6425fff33e4096b4e1fbfb954edae1349c0145

commit 0f6425fff33e4096b4e1fbfb954edae1349c0145
Author: ochang <ochang@chromium.org>
Date: Thu Apr 21 19:23:51 2016

Add a missing initialisation for CPDF_ContentMarkItem.

R=dsinclair@chromium.org
BUG= chromium:605491 

Review URL: https://codereview.chromium.org/1910143002

[modify] https://crrev.com/0f6425fff33e4096b4e1fbfb954edae1349c0145/core/fpdfapi/fpdf_page/cpdf_contentmarkitem.cpp

"By default we mark all use-of-uninitialized-value reports as Low severity." - in manual triage, we mark these as medium. Max, can you correct on severity of other bugs if you marked them low.

Oliver - thanks for adding the recommendation of medium for these.

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

commit 58b579ece9fcbc9d38ea9c186b4898685067d3ae
Author: ochang <ochang@chromium.org>
Date: Thu Apr 21 21:05:56 2016

Roll PDFium e3bbfa2..0f6425f

https://pdfium.googlesource.com/pdfium.git/+log/e3bbfa2..0f6425f

BUG= 605491 ,590711
TBR=dsinclair@chromium.org

TEST=bots

Review URL: https://codereview.chromium.org/1912763002

Cr-Commit-Position: refs/heads/master@{#388898}

[modify] https://crrev.com/58b579ece9fcbc9d38ea9c186b4898685067d3ae/DEPS

> Oliver - thanks for adding the recommendation of medium for these.

I meant a CL for this PDFium bug :)

But it should be a simple change to mark these as medium by default -- will do very soon too.

Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Requested label.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on omahaproxy.appspot.com.

- Your friendly ClusterFuzz

ClusterFuzz has detected this issue as fixed in range 388749:389333.

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

Fuzzer: ifratric_pdf_generic
Job Type: linux_msan_pdfium
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  CPDF_TextPage::PreMarkedContent
  CPDF_TextPage::ProcessTextObject
  CPDF_TextPage::ProcessTextObject
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_msan_pdfium&range=376900:376924
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_msan_pdfium&range=388749:389333

Minimized Testcase (7774.33 Kb): https://cluster-fuzz.appspot.com/download/AMIfv95n6FziRfnUqED5Mp5r4LosALM2xvuhiCt0RaAnPAaG68IW4wNs1wlRY82XK645zS7YABjcfN68N5zcWvr6AcaesVPfpTvtPiaVlopvne60edDQ7kcwdNu_T08qTpTGx3xw80___2kAQslQRAKbERDFrfP0jhj7SHay0xCqEtd3Ur1R818

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.

Requesting merges. 

[Automated comment] DEPS changes referenced in bugdroid comments, needs manual review.

[Automated comment] DEPS changes referenced in bugdroid comments, needs manual review.

Merge approved for M51 (branch 2704)

Please merge your change before 5:00 PM PST tomorrow (Tuesday) to M51 branch 2704, so we can take it for this week beta. Thank you.

Before we approve merge to M50, Could you please confirm whether this bug is baked and verified in Canary and safe to merge? 

The following revision refers to this bug:
  http://goto.ext.google.com/viewvc/chrome-internal?view=rev&revision=87063

------------------------------------------------------------------
r87063 | ochang@google.com | 2016-04-26T18:07:44.705754Z

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

govind, re #21. This is an extremely simple fix that is definitely safe to merge.

Thank you for confirmation. 
Approving merge to M50 branch 2661 based on comment #23. Please merge ASAP. Thank you.

The following revision refers to this bug:
  http://goto.ext.google.com/viewvc/chrome-internal?view=rev&revision=87077

------------------------------------------------------------------
r87077 | ochang@google.com | 2016-04-26T22:42:00.407000Z

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

ochang, did you check if this was reproducible with one of our libFuzzer pdfium fuzzers? Can we add this input to the corpora for libFuzzer fuzzer(s)?

Yes, I did check that it reproduces with the libFuzzer pdfium fuzzers, but the testcase here is unfortunately 7MB (minimized by CF) and probably not too useful to be added to our fuzzing corpus?

Yea, 7mb is not too useful (given that other fuzzers found this bug)

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

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

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