commit 71ff71b0f889d6c5e1b411c95b4255146bdc860c
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> Fri Jun 03 13:14:15 2022
tree 4f85b676ee2516a479c66c9082634f7bacca437a
parent 306eee3d179686a5aefa03bbee67be84707a9b5b

dcsctp: Reset send queue when recreating TCB

This is a re-land of commit 3180a5ad0663900a39adf4b9974052c356c835fe.

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: Ib8254488523c7abb58057c602f76f411fce896fa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265000
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37115}