Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

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

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

capn can you take a look at this? Thanks.

capn: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

I'm unable to reproduce this, and I don't see how it could be using uninitialized data since all the members are initialized in all constructor variants. The only exception is the default constructor, but that one should only be used very temporarily by an STL container before being overwritten.

Anyway, let's kill this with fire: https://swiftshader-review.googlesource.com/c/SwiftShader/+/16948

The following revision refers to this bug:
  https://swiftshader.googlesource.com/SwiftShader.git/+/bb2bcae3b81f456ea9479d5af36e6d1784f0b1e0

commit bb2bcae3b81f456ea9479d5af36e6d1784f0b1e0
Author: Nicolas Capens <capn@google.com>
Date: Mon Feb 05 18:05:30 2018

In-class initialize all TType members.

Also remove default constructors and unused members.

 Bug chromium:801648 

Change-Id: I822ca1e1569708ca661796ee9252bae68a0a284a
Reviewed-on: https://swiftshader-review.googlesource.com/16948
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

[modify] https://crrev.com/bb2bcae3b81f456ea9479d5af36e6d1784f0b1e0/src/OpenGL/compiler/OutputASM.cpp
[modify] https://crrev.com/bb2bcae3b81f456ea9479d5af36e6d1784f0b1e0/src/OpenGL/compiler/OutputASM.h
[modify] https://crrev.com/bb2bcae3b81f456ea9479d5af36e6d1784f0b1e0/src/OpenGL/compiler/SymbolTable.cpp
[modify] https://crrev.com/bb2bcae3b81f456ea9479d5af36e6d1784f0b1e0/src/OpenGL/compiler/Types.h

Hi capn@ - any more fire expected, or can this be marked as fixed?

We have to do a DEPS roll, but that's currently blocked by failures in newly added css3 tests. I'm in the middle of a significant refactoring to fix those, but that's delayed because I got hit by a gastro infection and I have heaps of other work to catch up on.

M65 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge  into the release branch ASAP. Thank you.

This isn't a regression and shouldn't be a release blocker, we'll remove the flag. We already have a fix for it and it will make it into the next release.

Does this CL also address any of issues in 797234, 797174, 796794, or 796776?

No, it doesn't address these other issues.
797234 is an uninitialized ConstantUnion::type
797174 and 796794 are uninitialized TPublicType::arraySize
796776 is already fixed in SwiftShader (see  http://crbug.com/796776#c11 ), we just need to roll into Chromium as soon as we're done with our current refactor.

The fix has rolled into Chromium, can we close this bug out?

It doesn't look like CF recognized the fix: https://clusterfuzz.com/v2/testcase-detail/6195868884795392?noredirect=1

I wasn't able to reproduce the issue locally before, and I'm still unable to reproduce it with tip-of-tree today. ClusterFuzz indicates it as "Fixed:	Pending", so I'm assuming there's a CF-specific issue remaining.

Closing this as Fixed and CC'ing mmoroz@ for potential follow-up.

Ah, now the problem might be that MSan is broken on Rodette. Here is the instruction on how MSan can be used locally https://www.chromium.org/developers/testing/memorysanitizer#TOC-Running-on-other-distros-using-Docker

As for the fix, I've just looked through the stacktrace, and it appears that the following function: https://cs.chromium.org/chromium/src/third_party/swiftshader/src/OpenGL/compiler/ParseHelper.cpp?type=cs&q=arraySizeErrorCheck&sq=package:chromium&l=798

may return true without initializing |size| value, which hasn't been initialized by the caller either: https://swiftshader.googlesource.com/SwiftShader/+/05bcbe6b7a2dffc284b38ad0f2731d2894972cd8/src/OpenGL/compiler/ParseHelper.cpp#1489

As a result, that uninitialized values ends up being assigned as an arraySize: https://swiftshader.googlesource.com/SwiftShader/+/05bcbe6b7a2dffc284b38ad0f2731d2894972cd8/src/OpenGL/compiler/ParseHelper.cpp#1496

You can also see how that uninitialized value has been propagated through a sequence of memcpy calls to the place where the error has been detected.

Actually, the return value of arraySizeErrorCheck doesn't seem to matter. The problem is that there are branches when size value is not initialized, and it's not initialized by default as well.

Thanks a ton for delving into this! It's unfortunate that MSan is broken on Rodete. Do you know of a bug report about it that we can follow?

I wasn't aware that the use-of-uninitialized-value error isn't reported on first assignment and thus propagation can occur first. So I wrongly assumed initializing class members during construction would fix this. Thanks again for digging deeper!

I'll look into the proper fix.

I'm not sure if there is any bug for tracking MSan on Rodete. +ochang@ who's been looking into that.

The following revision refers to this bug:
  https://swiftshader.googlesource.com/SwiftShader.git/+/858c0393b51e98025a9d0a4864985aecb4a3d5e5

commit 858c0393b51e98025a9d0a4864985aecb4a3d5e5
Author: Nicolas Capens <capn@google.com>
Date: Mon Apr 09 16:50:18 2018

Initialize array size on error.

The array size is set using the value returned by arraySizeErrorCheck,
even when an error occurred, so don't leave it uninitialized.

 Bug chromium:801648 

Change-Id: If2af27c5f61dca2931796f1681dce61ab6a44341
Reviewed-on: https://swiftshader-review.googlesource.com/18368
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

[modify] https://crrev.com/858c0393b51e98025a9d0a4864985aecb4a3d5e5/src/OpenGL/compiler/ParseHelper.cpp
[modify] https://crrev.com/858c0393b51e98025a9d0a4864985aecb4a3d5e5/src/OpenGL/compiler/glslang.y
[modify] https://crrev.com/858c0393b51e98025a9d0a4864985aecb4a3d5e5/src/OpenGL/compiler/glslang_tab.cpp

re #25, there are no plans to support MSan chromium on rodete. The only supported solution is https://www.chromium.org/developers/testing/memorysanitizer#TOC-Running-on-other-distros-using-Docker right now.

ClusterFuzz has detected this issue as fixed in range 550284:550296.

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

Fuzzer: libFuzzer_swiftshader_vertex_routine_fuzzer
Job Type: libfuzzer_chrome_msan
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  TType::operator==
  TParseContext::addTernarySelection
  yyparse
  
Sanitizer: memory (MSAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=521502:521555
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=550284:550296

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

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.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 6195868884795392 is verified as fixed, so closing issue as verified.

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