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.
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.
Metrics
Affected Vendors & Products
No data.
No data.
No data.
No data.
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Tue, 16 Sep 2025 08:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | sctp: check send stream number after wait_for_sndbuf | |
| References |
|
|
MITRE
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-09-16T08:11:28.519Z
Reserved: 2025-09-16T08:09:37.993Z
Link: CVE-2023-53296
Vulnrichment
No data.
NVD
No data.
Redhat
No data.
OpenCVE Enrichment
No data.