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

ClusterFuzz has detected this testcase as flaky and is unable to reproduce it in the original crash revision. Skipping fixed testing check and marking it as potentially fixed.

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

Fuzzer: phoglund_webrtc_peerconnection
Job Type: linux_asan_chrome_mp
Platform Id: linux

Crash Type: Heap-buffer-overflow WRITE 2
Crash Address: 0x61d0006df760
Crash State:
  sctp_send_deferred_reset_response
  sctp_process_data
  sctp_common_input_processing
  
Recommended Security Severity: High

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_mp&range=364779:365132

Unminimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv94VoXhooJoy_jYbLdKhW6OrO0RtyKltSO641SN531R6NWJC93mzGNIo54D7GcVgzWtTiCVa1XIZIhtGfsWfmCOT35CFihKkeaa7uKNfnrRpP-23ZQsAOfXGJo82FauzudZmIhFuDttBcPVlzT88htFO_7IOY87zbsBs2SYV88yqkhtQuG0?testcase_id=5002180864245760


Additional requirements: Requires HTTP

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

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

M53 is branching soon and will be promoted to Beta in July.Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix ASAP. Thank you. 

+guidou, +hta - this came off a WebRTC fuzzer, do you mind taking a look to see if it's relevant to you?

pthatcher@, can your team take a look at this, since this seems to be in the networking layer?
Otherwise I will take a look next week.

M53 is branching this week and will be promoted to Beta in July.Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix ASAP. Thank you.

I think this is not a regression.  Nothing in the list of recent change has anything to do with SCTP.  Further, we haven't changed any SCTP related code in a very long time.  

However, SCTP is implemented in a third-party library that has had a heap overflow in the past: https://bugs.chromium.org/p/chromium/issues/detail?id=516628.

I agree we should look into this a fix it, but I don't think it makes sense to block M53 beta on it.  

Looking at the code, it seems like it may be an actual issue. But I don't know how to even hit the "sctp_send_deferred_reset_response" method. lally@, can you offer any advice? I can't really make heads or tails of usrsctplib code.

M53 is branched today (2785) and will be promoted to Beta this month.Your bug is labelled as Beta ReleaseBlock, pls make sure to land and merge the fix to M53 branch 2785 by 5:00 PM PST on Friday 07/22 (sooner the better so it gets chance to bake in M53 dev releases it self). Thank you.

deadbeef: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

M53 beta launch is coming soon.Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix before 6:00 PM PST, Monday (07/18/16). Thank you.

I was able to reproduce and fix the issue locally, but how can we go about getting this into M53? The fix is in usrsctplib, a third party library. Can we make a branch of usrsctplib, specifically for the M53 release, and refer to it in the M53 DEPS? What's the proper process for this? I can't find anything on the wiki.

By the way, here's an explanation of how the issue occurs:

1. Two (or more) data channels are created.
2. A packet is sent on data channel 1, but it's dropped.
3. Before that packet is retransmitted, data channel 2 is closed, sending an "incoming stream reset" then "outgoing stream reset".
4. When the peer on the other side receives the outgoing reset, it defers sending a response because it's still waiting for that dropped packet.
5. When the dropped packet is received, it will send the deferred response. However, sctp_send_deferred_reset_response has a very obvious bug and will ALWAYS heap overflow.

This is just a code path that isn't hit very often. It requires a pretty precise timing of events, severe packet loss, and two data channels. If there's only one data channel, the outgoing stream reset won't even be sent until the dropped packet is acked.

Since this bug isn't a regression and is very unlikely to be encountered, I'm removing the release blocking label and moving the milestone to M54.

Fix has been upstreamed: https://github.com/sctplab/usrsctp/pull/93

Just need to update the usrsctp revision in DEPS now.

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

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

commit c259443691527968a5bcec022e41844fa606fd7e
Author: deadbeef <deadbeef@chromium.org>
Date: Tue Aug 02 18:05:45 2016

Roll src/third_party/usrsctp/usrsctplib/ c60ec8b35..9a3e5465e (180 commits).

https://chromium.googlesource.com/external/github.com/sctplab/usrsctp/+log/c60ec8b35c3f..9a3e5465e9d9

This roll includes a fix for a crash that was upstreamed:
https://github.com/sctplab/usrsctp/pull/93

Also replacing lally@ with pthatcher@ and deadbeef@ as owners of usrsctp, since Lally is no longer working on Chromium.

BUG= 622033 

Review-Url: https://codereview.chromium.org/2175453002
Cr-Commit-Position: refs/heads/master@{#409239}

[modify] https://crrev.com/c259443691527968a5bcec022e41844fa606fd7e/DEPS
[modify] https://crrev.com/c259443691527968a5bcec022e41844fa606fd7e/third_party/usrsctp/OWNERS

deadbeef: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Update: The roll above should have fixed this, but it's causing 3 new regressions so I may have to revert it.

Any updates on whether the fix got reverted, and if this is fixed?

I believe all the regressions are fixed now (see https://bugs.chromium.org/p/chromium/issues/detail?id=633959 for details), so this shouldn't need to be reverted. Updating the status.

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