CVE-2026-68315: sctp: validate stream count in sctp_process_strreset_inreq()

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

sctp: validate stream count in sctpprocessstrresetinreq()

When processing a RESETINREQUEST from a peer, sctpprocessstrresetinreq() derives the stream count from the parameter length but does not check whether the resulting RESETOUTREQUEST would exceed SCTPMAXCHUNKLEN.

The OUT request header (sctpstrresetoutreq, 16 bytes) is 8 bytes larger than the IN request header (sctpstrresetinreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a u16 overflow in sctpmakestrresetreq() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG:

net/core/skbuff.c:207 skbpanic net/core/skbuff.c:2625 skbput net/sctp/smmakechunk.c:1535 sctpaddtochunk net/sctp/smmakechunk.c:3695 sctpmakestrresetreq net/sctp/stream.c:655 sctpprocessstrresetinreq

The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer.

Reject peer IN requests whose corresponding OUT request would exceed SCTPMAXCHUNKLEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.

— NVD