NULL Pointer Dereference Affecting python3-perf package, versions <0:4.18.0-513.5.1.el8_9
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsSnyk Learn
Learn about NULL Pointer Dereference vulnerabilities in an interactive lesson.
Start learning- Snyk IDSNYK-CENTOS8-PYTHON3PERF-12856202
- published17 Sept 2025
- disclosed16 Sept 2025
Introduced: 16 Sep 2025
CVE-2023-53296 (opens in a new tab)How to fix?
Upgrade Centos:8 python3-perf to version 0:4.18.0-513.5.1.el8_9 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream python3-perf package and not the python3-perf package as distributed by Centos.
See How to fix? for Centos:8 relevant fixed versions and status.
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.
References
- https://access.redhat.com/security/cve/CVE-2023-53296
- 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