commit 3180a5ad0663900a39adf4b9974052c356c835fe
author Victor Boivie <boivie@webrtc.org> Thu May 05 10:08:37 2022
committer WebRTC LUCI CQ <webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com> Thu May 05 12:06:48 2022
tree 402e324d64d5f30e672a24cc158ea1dc8d90e059
parent 35ba0c5cd58f1d922b68ba06cfe2ccd5bb407a59

dcsctp: Reset send queue when recreating TCB

This is an issue found in fuzzer, and doesn't really happen in WebRTC
as it never closes the connection and reconnects.

The issue is that the send queue outlives any connection since you're
allowed to send messages (well, enqueue them) before the association is
fully connected. So the send queue is always present but the TCB
(information about the connection) is torn down when the connection is
closed for example. And the TCB holds the Stream Reset handler, which is
responsible for e.g. keeping track of stream reset sequence numbers and
such - which is tied to the connection.

So to ensure that the Stream Reset Handler is in charge of deciding
if a stream reset is taking place, make sure that the send queue is in
a known good state when the Stream Reset handler is created.

Bug: webrtc:13994, chromium:1320194
Change-Id: I940e4690ac9237ac99dd69a9ffc060cdac61711d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261260
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36779}