sctp: check send stream number after wait_for_sndbuf

In the Linux kernel, the following vulnerability has been resolved:

sctp: check send stream number after wait_for_sndbuf

This patch fixes a corner case where the asoc out stream count may change

after wait_for_sndbuf.

When the main thread in the client starts a connection, if its out stream

count is set to N while the in stream count in the server is set to N - 2,

another thread in the client keeps sending the msgs with stream number

N - 1, and waits for sndbuf before processing INIT_ACK.

However, after processing INIT_ACK, the out stream count in the client is

shrunk to N - 2, the same to the in stream count in the server. The crash

occurs when the thread waiting for sndbuf is awake and sends the msg in a

non-existing stream(N - 1), the call trace is as below:

KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]

Call Trace:

<TASK>

sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline]

sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline]

sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline]

sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170

sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163

sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868

sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026

inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825

sock_sendmsg_nosec net/socket.c:722 [inline]

sock_sendmsg+0xde/0x190 net/socket.c:745

The fix is to add an unlikely check for the send stream number after the

thread wakes up from the wait_for_sndbuf.