CVE-2023-53296

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

sctp: check send stream number after waitforsndbuf

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

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> sctpcmdsendmsg net/sctp/smsideeffect.c:1114 [inline] sctpcmdinterpreter net/sctp/smsideeffect.c:1777 [inline] sctpsideeffects net/sctp/smsideeffect.c:1199 [inline] sctpdosm+0x197d/0x5310 net/sctp/smsideeffect.c:1170 sctpprimitiveSEND+0x9f/0xc0 net/sctp/primitive.c:163 sctpsendmsgtoasoc+0x10eb/0x1a30 net/sctp/socket.c:1868 sctpsendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026 inetsendmsg+0x9d/0xe0 net/ipv4/afinet.c:825 socksendmsgnosec net/socket.c:722 [inline] socksendmsg+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 waitforsndbuf.