CVE-2025-23142

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: detect and prevent references to a freed transport in sendmsg<br /> <br /> sctp_sendmsg() re-uses associations and transports when possible by<br /> doing a lookup based on the socket endpoint and the message destination<br /> address, and then sctp_sendmsg_to_asoc() sets the selected transport in<br /> all the message chunks to be sent.<br /> <br /> There&amp;#39;s a possible race condition if another thread triggers the removal<br /> of that selected transport, for instance, by explicitly unbinding an<br /> address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have<br /> been set up and before the message is sent. This can happen if the send<br /> buffer is full, during the period when the sender thread temporarily<br /> releases the socket lock in sctp_wait_for_sndbuf().<br /> <br /> This causes the access to the transport data in<br /> sctp_outq_select_transport(), when the association outqueue is flushed,<br /> to result in a use-after-free read.<br /> <br /> This change avoids this scenario by having sctp_transport_free() signal<br /> the freeing of the transport, tagging it as "dead". In order to do this,<br /> the patch restores the "dead" bit in struct sctp_transport, which was<br /> removed in<br /> commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").<br /> <br /> Then, in the scenario where the sender thread has released the socket<br /> lock in sctp_wait_for_sndbuf(), the bit is checked again after<br /> re-acquiring the socket lock to detect the deletion. This is done while<br /> holding a reference to the transport to prevent it from being freed in<br /> the process.<br /> <br /> If the transport was deleted while the socket lock was relinquished,<br /> sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the<br /> send.<br /> <br /> The bug was found by a private syzbot instance (see the error report [1]<br /> and the C reproducer that triggers it [2]).