PT-2026-44350 · Linux · Linux

Published

2026-05-28

·

Updated

2026-05-28

·

CVE-2026-46227

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
sctp: revalidate list cursor after sctp sendmsg to asoc() in SCTP SENDALL
The SCTP SENDALL path in sctp sendmsg() iterates ep->asocs with list for each entry safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp sendmsg to asoc(), which may drop the socket lock inside sctp wait for sndbuf().
While the lock is dropped, another thread can SCTP SOCKOPT PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp sock migrate() (list del init() + list add tail() to newep->asocs), and optionally close the new socket which frees the association via kfree rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped.
sctp wait for sndbuf() revalidates @asoc (the current entry) on re-lock via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp association *).
Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init sid pointer.
Fix by re-deriving @tmp from @asoc after sctp sendmsg to asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list del an association from ep->asocs are sctp association free() (which sets asoc->base.dead) and sctp assoc migrate() (which changes asoc->base.sk), and sctp wait for sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive.
The SCTP ABORT path in sctp sendmsg check sflags() returns 0 and the loop hits 'continue' before sctp sendmsg to asoc() is ever called, so the @tmp cached by list for each entry safe() still covers the lock-held free that ba59fb027307 ("sctp: walk the list of asoc safely") was added for.

Related Identifiers

CVE-2026-46227

Affected Products

Linux