CVE-2023-53296
published 2025-09-16CVE-2023-53296: 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…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.14%
3.5th percentile
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:
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
20 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.25-1 (bookworm) | linux 6.1.25-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 5bbbbe32a43199c2b9ea5ea66fab6241c64beb51 < 9346a1a21142357972a6f466ba6275ddc54b04ac | 9346a1a21142357972a6f466ba6275ddc54b04ac |
| linux | linux | >= 5bbbbe32a43199c2b9ea5ea66fab6241c64beb51 < 0443fff49d6352160c200064156c25898bd9f58c | 0443fff49d6352160c200064156c25898bd9f58c |
| linux | linux | >= 5bbbbe32a43199c2b9ea5ea66fab6241c64beb51 < b4b6dfad41aaae9e36e44327b18d5cf4b20dd2ce | b4b6dfad41aaae9e36e44327b18d5cf4b20dd2ce |
| linux | linux | >= 5bbbbe32a43199c2b9ea5ea66fab6241c64beb51 < 667eb99cf7c15fe5b0ecefe75cf658e20ef20c9f | 667eb99cf7c15fe5b0ecefe75cf658e20ef20c9f |
| linux | linux | >= 5bbbbe32a43199c2b9ea5ea66fab6241c64beb51 < d2128636b303aa9cf065055402ee6697409a8837 | d2128636b303aa9cf065055402ee6697409a8837 |
| linux | linux | >= 5bbbbe32a43199c2b9ea5ea66fab6241c64beb51 < a615e7270318fa0b98bf1ff38daf6cf52d840312 | a615e7270318fa0b98bf1ff38daf6cf52d840312 |
| linux | linux | >= 5bbbbe32a43199c2b9ea5ea66fab6241c64beb51 < 2584024b23552c00d95b50255e47bd18d306d31a | 2584024b23552c00d95b50255e47bd18d306d31a |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.10.178-1 | 5.10.178-1 |
| linux | linux_kernel | >= 0 < 6.1.25-1 | 6.1.25-1 |
| linux | linux_kernel | >= 0 < 6.1.25-1 | 6.1.25-1 |
| linux | linux_kernel | >= 0 < 6.1.25-1 | 6.1.25-1 |
| linux | linux_kernel | >= 4.15 < 4.19.281 | 4.19.281 |
| linux | linux_kernel | >= 4.20 < 5.4.241 | 5.4.241 |
| linux | linux_kernel | >= 5.11 < 5.15.107 | 5.15.107 |
| linux | linux_kernel | >= 5.16 < 6.1.24 | 6.1.24 |
| linux | linux_kernel | >= 5.5 < 5.10.178 | 5.10.178 |
| linux | linux_kernel | >= 6.2 < 6.2.11 | 6.2.11 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
CVE-2023-53296: In the Linux kernel, the following vulnerability has been resolved: sctp: check send stream number after wait_for_sndbuf This patch fixes a corner cas
osv·2025-09-16·CVSS 5.5
CVE-2023-53296 [MEDIUM] CVE-2023-53296: In the Linux kernel, the following vulnerability has been resolved: sctp: check send stream number after wait_for_sndbuf This patch fixes a corner cas
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 ran
GHSA
GHSA-vwf3-3r65-6v22: In the Linux kernel, the following vulnerability has been resolved:
sctp: check send stream number after wait_for_sndbuf
This patch fixes a corner c
ghsa_unreviewed·2025-09-16
CVE-2023-53296 [MEDIUM] CWE-476 GHSA-vwf3-3r65-6v22: In the Linux kernel, the following vulnerability has been resolved:
sctp: check send stream number after wait_for_sndbuf
This patch fixes a corner c
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 i
Red Hat
kernel: sctp: check send stream number after wait_for_sndbuf
vendor_redhat·2025-09-16·CVSS 5.5
CVE-2023-53296 [MEDIUM] CWE-476 kernel: sctp: check send stream number after wait_for_sndbuf
kernel: 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
Debian
CVE-2023-53296: linux - In the Linux kernel, the following vulnerability has been resolved: sctp: check...
vendor_debian·2023·CVSS 5.5
CVE-2023-53296 [MEDIUM] CVE-2023-53296: linux - In the Linux kernel, the following vulnerability has been resolved: sctp: check...
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 ran
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/0443fff49d6352160c200064156c25898bd9f58chttps://git.kernel.org/stable/c/2584024b23552c00d95b50255e47bd18d306d31ahttps://git.kernel.org/stable/c/667eb99cf7c15fe5b0ecefe75cf658e20ef20c9fhttps://git.kernel.org/stable/c/9346a1a21142357972a6f466ba6275ddc54b04achttps://git.kernel.org/stable/c/a615e7270318fa0b98bf1ff38daf6cf52d840312https://git.kernel.org/stable/c/b4b6dfad41aaae9e36e44327b18d5cf4b20dd2cehttps://git.kernel.org/stable/c/d2128636b303aa9cf065055402ee6697409a8837
2025-09-16
Published