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.
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.
Update Linux/Linux to f3a3f0b406b4b7eb3cea35a23fa2bf170848b104 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scansctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL affects Linux/Linux (generic), Linux/Linux (generic). Severity is high. 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.
AI coding agents often install or upgrade packages automatically in generic. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=4910280503f3af2857d5aa77e35b22d93a8960a8 <f3a3f0b406b4b7eb3cea35a23fa2bf170848b104 || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <0dbc8cde64280fc37cdd678cced34eaf96cfb197 || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <0c7b55974f97b78d1109025eadf084e74cbf330f || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <1bfb06ecb00f7fdf35dba8e8f2877346cbe5e078 || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <6187a172d6ed57d6b2c327836e4407c6456e639d || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <c9dadb31f36045a8cb65df4bd75e7237ef21a4b5 || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <bf0f40d8107e2ce827521968dc6926f3e13728ae || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <abb5f36771cc4c05899b34000829a787572a8817 | f3a3f0b406b4b7eb3cea35a23fa2bf170848b104, 0dbc8cde64280fc37cdd678cced34eaf96cfb197, 0c7b55974f97b78d1109025eadf084e74cbf330f, 1bfb06ecb00f7fdf35dba8e8f2877346cbe5e078, 6187a172d6ed57d6b2c327836e4407c6456e639d, c9dadb31f36045a8cb65df4bd75e7237ef21a4b5, bf0f40d8107e2ce827521968dc6926f3e13728ae, abb5f36771cc4c05899b34000829a787572a8817 |
| Linux/Linuxgeneric | 4.17 | Not reported |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by CVE List V5 (cvelist).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate Linux/Linux to f3a3f0b406b4b7eb3cea35a23fa2bf170848b104 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scansctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL affects Linux/Linux (generic), Linux/Linux (generic). Severity is high. 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.
AI coding agents often install or upgrade packages automatically in generic. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=4910280503f3af2857d5aa77e35b22d93a8960a8 <f3a3f0b406b4b7eb3cea35a23fa2bf170848b104 || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <0dbc8cde64280fc37cdd678cced34eaf96cfb197 || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <0c7b55974f97b78d1109025eadf084e74cbf330f || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <1bfb06ecb00f7fdf35dba8e8f2877346cbe5e078 || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <6187a172d6ed57d6b2c327836e4407c6456e639d || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <c9dadb31f36045a8cb65df4bd75e7237ef21a4b5 || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <bf0f40d8107e2ce827521968dc6926f3e13728ae || >=4910280503f3af2857d5aa77e35b22d93a8960a8 <abb5f36771cc4c05899b34000829a787572a8817 | f3a3f0b406b4b7eb3cea35a23fa2bf170848b104, 0dbc8cde64280fc37cdd678cced34eaf96cfb197, 0c7b55974f97b78d1109025eadf084e74cbf330f, 1bfb06ecb00f7fdf35dba8e8f2877346cbe5e078, 6187a172d6ed57d6b2c327836e4407c6456e639d, c9dadb31f36045a8cb65df4bd75e7237ef21a4b5, bf0f40d8107e2ce827521968dc6926f3e13728ae, abb5f36771cc4c05899b34000829a787572a8817 |
| Linux/Linuxgeneric | 4.17 | Not reported |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by CVE List V5 (cvelist).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard