Predator and CL could not provide any possible suspects.
Using Code Search for the file, "webm_cluster_parser.cc" assigning to the concern owner who might be related.

@dalecurtis --Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

It looks like a few bad things are going on here that need fixing:
1) Left-shifting a negative value.
2) Negative padding is allowed per webm container spec (meaning drop from the front, not the back), but we apply a negative drop to the back).
3) Lack of unit tests for negative padding.

Note, this may be part of the experiment noise in internal b/28447708

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

For more information, please see https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md.

The link referenced in the description is no longer valid.

ClusterFuzz has detected this issue as fixed in range 548850:548860.

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

Fuzzer: libFuzzer_mediasource_WEBM_OPUS_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: Undefined-shift
Crash Address: 
Crash State:
  media::WebMClusterParser::OnBinary
  media::ParseBinary
  media::ParseNonListElement
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=499820:499882
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=548850:548860

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

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

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

I confirmed with a local repro that this is NOT fixed.

Chris, please take a look or assign back to me for load-balancing.
For future reference, there is a significant amount of error in the CF verification of fixed (including #9), warranting manual inspection/verification when there isn't an obviously fix that's landed.

+mmoroz@ as FYI w.r.t. this ClusterFuzz-Wrong problem. I've seen a few of these recently, more than I would have wished. Is there something in the infra that's making the false-fixed notifications more prevalent?

Thanks for reporting that, wolenetz@. That sounds bad.

I wonder if recently added pointer-overflow check could cause that. I don't see a pointer-overflow crash though. I'll try it locally too.

I'm able to reproduce it locally as well. Filed issue 836810. Sorry for the inconvenience and thanks again for reporting.

Just clicked Redo->Check bug if it still reproduces. ClusterFuzz is able to reproduce this on latest revision. See

[2018-04-25 15:11:35 UTC] aarya@google.com: Redo task(s): progression
[2018-04-25 15:14:03 UTC] clusterfuzz-linux-high-end-sjxl: Progression task started: r553531.
[2018-04-25 15:15:23 UTC] clusterfuzz-linux-high-end-sjxl: Progression task finished.


I think this incorrect fixed notification was caused by pointer overflow check which we enabled and caused a startup crash in skia. now we have the suppression. sorry for noise.

For such an issue that gets incorrectly marked by CF as "Fixed" and "Verified", why didn't another bug get filed or this bug get reactivated by CF re-detecting a repro (perhaps with similar corpus input)? Was CF just unlucky and not yet reaching a run that mirrored the original repro case? Or is there some filter in CF infra that says never to reopen a bug/create a new bug that looks just like one that we've previously said is "Fixed/Verified"? IMHO, the former would be sad/unexpected (variants of known previous failure cases should be tested more frequently), and the latter would be a bug.

wolenetz@, there are different scenarios possible for why an issue can be incorrectly marked by Fixed or Verified. For most of the scenarios, CF is able to file another bug later (can take a couple days though, as it has to do re-grouping of similar crashes) or re-open the same issue.

In this particular case, we believe the flakiness has been caused by changes on Chrome build side, where CF doesn't have much control, and we obviously can't proactively handle any build / instrumentation changes. Unfortunately, we have to investigate such cases and process them manually or add new handling functionality to CF, when it's possible.

ClusterFuzz testcase 4713238062432256 appears to be flaky, updating reproducibility label.

Please ignore the last comment about testcase being unreproducible. The testcase is still reproducible. This happened due to a code refactoring on ClusterFuzz side, and the underlying root cause is now fixed. Resetting the label back to Reproducible. Sorry about the inconvenience caused from these incorrect notifications.

Please ignore the last comment about testcase being unreproducible. The testcase is still reproducible. This happened due to a code refactoring on ClusterFuzz side, and the underlying root cause is now fixed. Resetting the label back to Reproducible. Sorry about the inconvenience caused from these incorrect notifications.

ClusterFuzz has detected this issue as fixed in range 615699:615711.

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

Fuzzer: libFuzzer_mediasource_WEBM_OPUS_pipeline_integration_fuzzer
Fuzz target binary: mediasource_WEBM_OPUS_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: Undefined-shift
Crash Address: 
Crash State:
  media::WebMClusterParser::OnBinary
  media::ParseBinary
  media::ParseNonListElement
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=499820:499882
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=615699:615711

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

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

mmoroz@ is #20's "Fixed" legit? Fixed range shows no reason for fix (though there was a ubsan bot config change in the range making me more strongly suspect this issue is not really fixed (https://chromium.googlesource.com/chromium/src/+/85102b19f89daf824e9581f17208c2f848788c4d)

Sorry about that, I've unintentionally broken bunch of UBSan crashes, fixing them right now.