ossu@ could you please look into this.please feel free to re-assigned back if needed. thanks in advance !

I don't feel particularly responsible for this code (nor for  issue 653267 ). I believe they both came into being (noticed) by hlundin creating the fuzzer that caught these. At least this one seems to have been written by him as well. Perhaps reassign to hlundin and have him delegate if necessary? (Which I realize might have it end up back in my lap anyways :)).

Added hlundin for visibility.
Noticed there's a reference to RFC 3550. I'll have a look at what it says and see if I can figure this one out. Looking at the code[1], it's clear that the issue can happen in this artificial case, but maybe there's also problems with wrap-around. Maybe (even) the RFC is mistaken in its algorithm.

Is this really priority 1?

[1] https://cs.chromium.org/chromium/src/third_party/webrtc/modules/audio_coding/neteq/rtcp.cc?q=rtcp.cc:50&sq=package:chromium&dr&l=50

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/6b6c88f18428deddf0defdf37fc77a21eef36c47

commit 6b6c88f18428deddf0defdf37fc77a21eef36c47
Author: ossu <ossu@webrtc.org>
Date: Mon Oct 31 15:59:26 2016

NetEq jitter calculation now done in uint64_t.

The timestamps are 32 bit and can (conceivably) be spaced far enough
apart for the calculation, which is done in Q4, to overflow.

BUG= chromium:653268 

Review-Url: https://codereview.webrtc.org/2460393002
Cr-Commit-Position: refs/heads/master@{#14856}

[modify] https://crrev.com/6b6c88f18428deddf0defdf37fc77a21eef36c47/webrtc/modules/audio_coding/neteq/rtcp.cc
[modify] https://crrev.com/6b6c88f18428deddf0defdf37fc77a21eef36c47/webrtc/modules/audio_coding/neteq/rtcp.h

Turns out wrap-around was not a problem, but large timestamp changes were. This shouldn't happen during a normal stream, but could happen during fuzzing.

ClusterFuzz has detected this issue as fixed in range 428756:428832.

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

Fuzzer: libfuzzer_neteq_rtp_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: Undefined-shift
Crash Address: 
Crash State:
  webrtc::Rtcp::Update
  webrtc::NetEqImpl::InsertPacketInternal
  webrtc::NetEqImpl::InsertPacket
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_ubsan&range=423119:423133
Fixed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_ubsan&range=428756:428832

Minimized Testcase (0.02 Kb): https://cluster-fuzz.appspot.com/download/AMIfv95zJPzI2Mf4-9yRTvQ6OxpWrew426500CG9zMwxI9kYbNRmYs98CwRJM70X5uW_L9CHHyLAZYnLFKjsuH1sGI95fA-RR8PeciCQWb5Dq8xF1DBcI8K3CLulNKlFozKzCUTxGFEF8B8F_FQ1ZkFqTCVLqjNkyw?testcase_id=4989302897639424

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

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

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

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