Findit results:
--------------------

Suspected CLs	The result is a list of CLs that change the crashed files.

Author: kwiberg
Project: chromium-webrtc
Changelist: https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+/b9a5d2a304565d81be4a562deabd8397cc9a818a
Time: Tue Oct 04 16:33:27 2016
File neteq_impl.cc is changed in this cl (and is part of stack frame #2, "webrtc::NetEqImpl::GetDecision"; frame #3, "webrtc::NetEqImpl::GetAudioInternal"; frame #4, "webrtc::NetEqImpl::GetAudio")
Minimum distance from crash line to modified line: 72. (file: neteq_impl.cc, crashed on: 210, modified: 282).

Suspected Project: chromium-webrtc
Suspected Component: Blink>Webrtc


based on Findit results, assigning to kwiberg@, could you please check the issue and help.

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

The immediate problem is that in the following code, timestamp_diff becomes INT32_MIN, which overflows when we try to negate it on the last line:

Operations DecisionLogicNormal::CngOperation(Modes prev_mode,
                                             uint32_t target_timestamp,
                                             uint32_t available_timestamp,
                                             size_t generated_noise_samples) {
  // Signed difference between target and available timestamp.
  int32_t timestamp_diff = static_cast<int32_t>(
      static_cast<uint32_t>(generated_noise_samples + target_timestamp) -
      available_timestamp);
  int32_t optimal_level_samp = static_cast<int32_t>(
      (delay_manager_->TargetLevel() * packet_length_samples_) >> 8);
  int32_t excess_waiting_time_samp = -timestamp_diff - optimal_level_samp;

First I thought I could solve it by just doing the arithmetic in 64 bits, but perhaps a sanity check is in order first? Is it a "benign" overflow, or a sign that something has gone wrong earlier?

Can we have an update on this issue? Henrik, are you looking at it?

Ping.

Did not look at this yet.

ivoc@, would you mind taking a look. I'm out of cycles.

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

commit e3fc11464e5b295c53c897d3dcb4da0cdf10fc21
Author: ivoc <ivoc@webrtc.org>
Date: Tue May 16 14:13:15 2017

Fixed NetEq overflow bug.

Negating an int can result in a value that cannot be represented as an int. This is fixed here by using a 64 bit variable.

BUG= chromium:663611 

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

[modify] https://crrev.com/e3fc11464e5b295c53c897d3dcb4da0cdf10fc21/webrtc/modules/audio_coding/neteq/decision_logic_normal.cc

ClusterFuzz has detected this issue as fixed in range 472379:472409.

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

Fuzzer: libfuzzer_neteq_rtp_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: Integer-overflow
Crash Address: 
Crash State:
  webrtc::DecisionLogicNormal::CngOperation
  webrtc::DecisionLogic::GetDecision
  webrtc::NetEqImpl::GetDecision
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=423119:423133
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=472379:472409

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


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.