assigning to guidou who spans both chrome/webrtc universes, can you please assign as appropriate to someone upstream?  Thanks.

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

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

**** Bulk edit -  please ignore if not applicable ****

This bug  is reported as M55 Beta blocker and we're getting closer to M55 Beta promotion. 
Please plan to have fix ready and merged to M55 branch (2883) by 5:00 PM PT, Monday(10/10) so it has enough baking time in Dev before Beta promotion. Thank you.

Clusterfuzz suggests this regression was introduced by https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+/b9a5d2a304565d81be4a562deabd8397cc9a818a, so adding kwiberg@ who might be able to shed some light.  Thanks!

ClusterFuzz has detected this issue as fixed in range 425650:425670.

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

Fuzzer: afl_neteq_rtp_fuzzer
Job Type: afl_chrome_asan
Platform Id: linux

Crash Type: Heap-buffer-overflow READ 2
Crash Address: 0x60d000001118
Crash State:
  WebRtcSpl_MaxIndexW16
  webrtc::DspHelper::PeakDetection
  webrtc::Merge::CorrelateAndPeakSearch
  
Recommended Security Severity: Medium

Regressed: https://cluster-fuzz.appspot.com/revisions?job=afl_chrome_asan&range=423127:423154
Fixed: https://cluster-fuzz.appspot.com/revisions?job=afl_chrome_asan&range=425650:425670

Minimized Testcase (0.94 Kb): https://cluster-fuzz.appspot.com/download/AMIfv95ne1zhqxuPR-o6l-Izv-_sS_SPOoiLtjSpmXivlxOi6k6koh2S7lNiZvt4ytqH_xQ-C5vO9O7dsKLy3OsYJLyiwadsjtx-ZRESbl84fojTbdaJd22-PpPEUygBo7fSvCr7GUqUVrKhu7IcveHDw-1C_qDdWw?testcase_id=4703881181528064

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.

I'll re-open this, since it looks scary. I'd like to know that the problem has indeed sorted itself out, and not just been swept under the carpet...

awhalley@, could you PTAL as this is reported as this is blocking this week Beta release on Wednesday.

Setting status to assigned just to get this out of the security triage queue. Let me know if you need help verifying that it was actually fixed.

Is this bug specific to Linux only (doesn't affect any other OSs)?

This is blocking this week Beta release on Wednesday (10/26). Fix has to be landed/merged to M55 branch 2883 before 5:00 PM PT tomorrow, Tuesday (10/25). Thank you.

The WebRTC commit that made the bug disappear is this one:

commit c9ec8758db79c6fe4dee42d785f681931ddd7911
Author: henrik.lundin <henrik.lundin@webrtc.org>
Date:   Thu Oct 13 02:43:34 2016 -0700

    NetEq: Remove special case for Merge without Expand
    
    This was an ill tested special case which turned out to be more problem
    than benefit. The special case was only triggered when the decoder frame
    size was smaller than 10 ms, which is more or less unsupported by NetEq.
    
    Also fixed a bug in a test, a bug which was exposed by the code change.
    
    BUG= chromium:654983 
    
    Review-Url: https://codereview.webrtc.org/2412883002
    Cr-Commit-Position: refs/heads/master@{#14627}

(OK, don't know why the OS flag got changed. Changing it back...)

WebRTC CL that backports the fix to WebRTC's M55 branch (not yet landed): https://codereview.webrtc.org/2445373002/

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

commit c64c620c83176c6766d3e150558bc866ebb7f7c5
Author: Karl Wiberg <kwiberg@google.com>
Date: Tue Oct 25 12:09:55 2016

NetEq: Remove special case for Merge without Expand

(This is a backport of revision 14627 (c9ec8758db79c6fe4de). Original
CL here: https://codereview.webrtc.org/2412883002)

This was an ill tested special case which turned out to be more problem
than benefit. The special case was only triggered when the decoder frame
size was smaller than 10 ms, which is more or less unsupported by NetEq.

Also fixed a bug in a test, a bug which was exposed by the code change.

BUG= chromium:654983 ,  chromium:653656 
R=ossu@webrtc.org

Review URL: https://codereview.webrtc.org/2445373002 .

Cr-Commit-Position: refs/branch-heads/55@{#2}
Cr-Branched-From: 085ec0e4b1c0a17b024ac9cf399cd5a62e07ec99-refs/heads/master@{#14500}

[modify] https://crrev.com/c64c620c83176c6766d3e150558bc866ebb7f7c5/webrtc/modules/audio_coding/neteq/decision_logic_normal.cc
[modify] https://crrev.com/c64c620c83176c6766d3e150558bc866ebb7f7c5/webrtc/modules/audio_coding/neteq/decision_logic_normal.h
[modify] https://crrev.com/c64c620c83176c6766d3e150558bc866ebb7f7c5/webrtc/modules/audio_coding/neteq/neteq_impl_unittest.cc

The CL landed in comment #21 is a backport of the CL that fixed the bug in WebRTC's master branch to WebRTC's M55 branch. Since the WebRTC branch entry in DEPS is unpinned, this backport ought to roll right into Chromium with no further human intervention.

Setting this bug to Fixed.

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