CVE-2023-53296: linux kernel Null Dereference — Fix

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.

Is your site exposed to CVE-2023-53296?

Run a free security scan — no signup, results in seconds.

CVSS v3.1 Score

5.5

MEDIUM

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Weakness Type (CWE)

CWE-476 CWE-476

Affected Products

Vendor	Product	Versions
linux	linux_kernel	4.15 — 4.19.281
linux	linux_kernel	4.20 — 5.4.241
linux	linux_kernel	5.5 — 5.10.178
linux	linux_kernel	5.11 — 5.15.107
linux	linux_kernel	5.16 — 6.1.24
linux	linux_kernel	6.2 — 6.2.11
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All

References

Advisories & Patches

https://git.kernel.org/stable/c/0443fff49d6352160c200064156c25898bd9f58c https://git.kernel.org/stable/c/2584024b23552c00d95b50255e47bd18d306d31a https://git.kernel.org/stable/c/667eb99cf7c15fe5b0ecefe75cf658e20ef20c9f https://git.kernel.org/stable/c/9346a1a21142357972a6f466ba6275ddc54b04ac https://git.kernel.org/stable/c/a615e7270318fa0b98bf1ff38daf6cf52d840312 https://git.kernel.org/stable/c/b4b6dfad41aaae9e36e44327b18d5cf4b20dd2ce https://git.kernel.org/stable/c/d2128636b303aa9cf065055402ee6697409a8837

Frequently Asked Questions

What is 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 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. It has a CVSS v3.1 base score of 5.5 (MEDIUM).

How severe is CVE-2023-53296? +

CVE-2023-53296 has a CVSS v3.1 score of 5.5 out of 10, rated MEDIUM. This is a medium-severity vulnerability that should be remediated as part of regular maintenance.

What products are affected by CVE-2023-53296? +

CVE-2023-53296 affects products from linux, specifically: linux_kernel. Check the affected products table above for specific version ranges.

How do I check if I'm vulnerable to CVE-2023-53296? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2026-8479

IEC 60870-5-104 used in bidirectional mode in RTU500 is vulnerable for a NULL pointer dereferencing, if a specially crafted sequence …

CVE-2025-24031

PAM-PKCS#11 is a Linux-PAM login module that allows a X.509 certificate based user login. In versions 0.6.12 and prior, the …

CVE-2025-31115

XZ Utils provide a general-purpose data-compression library plus command-line tools. In XZ Utils 5.3.3alpha to 5.8.0, the multithreaded .xz decoder …

CVE-2025-0121

A null pointer dereference vulnerability in the Palo Alto Networks Cortex® XDR agent on Windows devices allows a low-privileged local …

CVE-2023-45925

GNU Midnight Commander 4.8.29-146-g299d9a2fb was discovered to contain a NULL pointer dereference via the function x_error_handler() at tty/x11conn.c. NOTE: this …

CVE-2025-6398

A null pointer dereference vulnerability exists in the IOMap64.sys driver of ASUS AI Suite 3. The vulnerability can be triggered …

CVE-2023-53296