Entreprise française de cybersécurité depuis 2004
☎ 03 60 47 09 81 - info@securiteinfo.com
☎ 03 60 47 09 81 - info@securiteinfo.com
In the Linux kernel, the following vulnerability has been resolved:sctp: detect and prevent references to a freed transport in sendmsgsctp_sendmsg() re-uses associations and transports when possible bydoing a lookup based on the socket endpoint and the message destinationaddress, and then sctp_sendmsg_to_asoc() sets the selected transport inall the message chunks to be sent.There's a possible race condition if another thread triggers the removalof that selected transport, for instance, by explicitly unbinding anaddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks havebeen set up and before the message is sent. This can happen if the sendbuffer is full, during the period when the sender thread temporarilyreleases the socket lock in sctp_wait_for_sndbuf().This causes the access to the transport data insctp_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() signalthe freeing of the transport, tagging it as "dead". In order to do this,the patch restores the "dead" bit in struct sctp_transport, which wasremoved incommit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").Then, in the scenario where the sender thread has released the socketlock in sctp_wait_for_sndbuf(), the bit is checked again afterre-acquiring the socket lock to detect the deletion. This is done whileholding a reference to the transport to prevent it from being freed inthe process.If the transport was deleted while the socket lock was relinquished,sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry thesend.The bug was found by a private syzbot instance (see the error report [1]and the C reproducer that triggers it [2]).
No PoCs from references.
- https://github.com/w4zu/Debian_security