Redo Task has been performed for a better regression range.
Thank You.

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

Testcase 5097185053245440 is a top crash on ClusterFuzz for linux platform. Please prioritize fixing this crash.

Marking this crash as a Beta release blocker.

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

TBH I'm not familiar with that code myself. As far as I can tell the UB gets triggered at https://cs.chromium.org/chromium/src/media/formats/mp2t/timestamp_unroller.cc?rcl=ecc1021b293738ffcabc4c049379b40959f1a512&l=52 when previous_unrolled_time_high is 0 and thus we try to evaluate -1 << 33, which is apparently an undefined behavior in C/C++. Peter, could you please take a look at this? Can we perhaps rewrite the calculations in TimestampUnroller::GetUnrolledTimestamp to avoid UB?

AS Zqiu last visit>30 days,could someone from cc'ed dev  please take a look into this issue as we have scheduled beta release on 10/11 and this is marked as Beta blocker .
Thanks..!

Sorry for the delay. Will look into it.

CL uploaded for review: https://chromium-review.googlesource.com/c/chromium/src/+/709854

So how do I run libFuzzer_mediasource_MP2T_AVC_pipeline_integration_fuzzer to verify the fix?

M63 is branching on this Thursday (10/12) and M63 beta promotion is coming very soon. Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix ASAP. Thank you.

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

commit d6c19dbb202fcf130f58db70d52ff208818374c3
Author: Peter Qiu <zqiu@chromium.org>
Date: Wed Oct 11 00:32:01 2017

mp2t: update timestamp unrolller calculation

The previous calculation code will always result in the left
shifting of a negative number when processing the second
timestamp, since only the first 33 bits of |previous_unrolled_timestamp|
will be set after processing the first timestamp.

So update the calulation to avoids this issue, which is more inlined
with the documented formula.

Bug:  762471 
Test: run media_unittests
Change-Id: I50b0f73beda22b3ee7722b4b299a6c3e4a3571c0
Reviewed-on: https://chromium-review.googlesource.com/709854
Reviewed-by: Sergey Volk <servolk@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Peter Qiu <zqiu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#507841}
[modify] https://crrev.com/d6c19dbb202fcf130f58db70d52ff208818374c3/media/formats/mp2t/timestamp_unroller.cc

ClusterFuzz has detected this issue as fixed in range 507830:507845.

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

Fuzzer: libFuzzer_mediasource_MP2T_AVC_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: Undefined-shift
Crash Address: 
Crash State:
  media::mp2t::TimestampUnroller::GetUnrolledTimestamp
  media::mp2t::TsSectionPes::ParseInternal
  media::mp2t::TsSectionPes::Emit
  
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=507830:507845

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

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

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

Looks fixed by the m63 roll (commit 49e240c638f34c4a456fc2c80697161aeb23548c).

No, actually it's been fixed by Peter's CL:
https://chromium-review.googlesource.com/c/chromium/src/+/709854

Ah, sorry - mixed up my bugs.