CVE-2025-23142
Last modified
CVE-2025-23142 is a high-severity vulnerability rated 7.8/10 on the CVSS scale. In the Linux kernel, the following vulnerability has been resolved: sctp: detect and prevent references to a freed transport in sendmsg sctp_sendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctp_sendmsg_to_asoc() sets the selected transport in all the message chunks to be sent. There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctp_wait_for_sndbuf(). This causes the access to the transport data in sctp_outq_select_transport(), when the association outqueue is flushed, to result in a use-after-free read. This change avoids this scenario by having sctp_transport_free() signal the freeing of the transport, tagging it as "dead". EPSS estimates a 0.20% chance of exploitation in the next 30 days.
Description
In the Linux kernel, the following vulnerability has been resolved: sctp: detect and prevent references to a freed transport in sendmsg sctp_sendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctp_sendmsg_to_asoc() sets the selected transport in all the message chunks to be sent. There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctp_wait_for_sndbuf(). This causes the access to the transport data in sctp_outq_select_transport(), when the association outqueue is flushed, to result in a use-after-free read. This change avoids this scenario by having sctp_transport_free() signal the freeing of the transport, tagging it as "dead". In order to do this, the patch restores the "dead" bit in struct sctp_transport, which was removed in commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport"). Then, in the scenario where the sender thread has released the socket lock in sctp_wait_for_sndbuf(), the bit is checked again after re-acquiring the socket lock to detect the deletion. This is done while holding a reference to the transport to prevent it from being freed in the process. If the transport was deleted while the socket lock was relinquished, sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the send. The bug was found by a private syzbot instance (see the error report [1] and the C reproducer that triggers it [2]).
Metrics
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weakness Enumeration
Affected Software
| Vendor | Product | Versions | Update |
|---|---|---|---|
| Linux | Linux Kernel | >= 3.18.128, < 3.19 | — |
| Linux | Linux Kernel | >= 4.4.166, < 4.5 | — |
| Linux | Linux Kernel | >= 4.9.142, < 4.10 | — |
| Linux | Linux Kernel | >= 4.14.85, < 4.15 | — |
| Linux | Linux Kernel | >= 4.19.6, < 5.4.293 | — |
| Linux | Linux Kernel | >= 5.5, < 5.10.237 | — |
| Linux | Linux Kernel | >= 5.11, < 5.15.181 | — |
| Linux | Linux Kernel | >= 5.16, < 6.1.135 | — |
| Linux | Linux Kernel | >= 6.2, < 6.6.88 | — |
| Linux | Linux Kernel | >= 6.7, < 6.12.24 | — |
| Linux | Linux Kernel | >= 6.13, < 6.13.12 | — |
| Linux | Linux Kernel | >= 6.14, < 6.14.3 | — |
| Linux | Linux Kernel | 6.15 | Rc1 |
| Debian | Debian Linux | 11.0 | — |
References
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.htmlMailing List, Third Party Advisory
- https://lists.debian.org/debian-lts-announce/2025/05/msg00045.htmlMailing List, Third Party Advisory
Timeline
- Published
- Last Modified
- Status
- Modified
Frequently Asked Questions
What is CVE-2025-23142?
How severe is CVE-2025-23142?
How do I fix CVE-2025-23142?
How Strix Helps
- How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
- Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
- PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
- AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.
Related CVEs from 2025
- CVE-2025-23137In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2025-23138In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2025-23139Rejected reason: This CVE ID has been rejected or withdrawn …
- CVE-2025-2314The User Profile Builder – Beautiful User Registration Forms…6.4
- CVE-2025-23140In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2025-23141In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2025-23143In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2025-23144In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2025-23145In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2025-23146In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2025-23147In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2025-23148In the Linux kernel, the following vulnerability has been re…5.5
Are you affected by CVE-2025-23142?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
