CVE-2026-98846: sctp: check RCV_SHUTDOWN after the sendmsg connect wait
In the Linux kernel, the following vulnerability has been resolved:
sctp: check RCVSHUTDOWN after the sendmsg connect wait
sctpwaitforconnect() drops the socket lock while it sleeps. An out-of-the-blue ABORT can then be processed from the socket backlog and unlink the association. If a concurrent shutdown(fd, SHUTRD) sets RCVSHUTDOWN, the waiter breaks with err == 0 before checking asoc->base.dead. Its final sctpassociationput() can then free the association, leaving sctpsendmsgtoasoc() to continue with a dangling pointer.
Check RCVSHUTDOWN along with the wait error in sctpsendmsgtoasoc() before using the association again. The check only accesses the socket, so it needs no additional association reference. Return the existing -ESRCH so that sctpsendmsg() skips freeing a new association that may already have been destroyed.
Keep sctpwaitforconnect() unchanged to preserve its behavior for the connect() caller.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
The issue requires SCTP sendmsg() to be waiting for an association connection while the socket lock is dropped. During that wait, an out-of-the-blue SCTP ABORT must unlink the association and a concurrent shutdown(fd, SHUT_RD) must set RCV_SHUTDOWN.
Is this limited to a particular SCTP operation?
Yes. The affected path is sctp_sendmsg_to_asoc() after its connect wait completes. The related connect() behavior is intentionally left unchanged by the fix.
What happens if the vulnerable race is reached?
The association can be freed while sctp_sendmsg_to_asoc() still retains a pointer to it. Continuing to use that dangling pointer can result in a use-after-free condition.
What does the fix change?
The fix checks RCV_SHUTDOWN together with the wait error before sctp_sendmsg_to_asoc() uses the association again. It returns -ESRCH so sctp_sendmsg() does not free a newly created association that may already have been destroyed.