Back

MEDIUM

sctp: check send stream number after wait_for_sndbuf

Published Sep 16, 2025

Description

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.

Affected products

Remediation

No remediation recorded yet.

References (13)

Change history (0)

No recorded changes yet.

Sources
CVE.org / MITRE
Status PUBLISHED
Assigner Linux
Published Sep 16, 2025
Updated May 11, 2026
Reserved Sep 16, 2025
CISA Vulnrichment
Updated Jan 14, 2026
NVD
Status Modified
Modified Jun 17, 2026
Red Hat
Severity Moderate
Public date Sep 16, 2025
ENISA EUVD
Assigner Linux
Published Sep 16, 2025
Updated May 11, 2026
Exploited since n/a
EUVD-2023-59893