CVE-2026-46227
Analyzed Analyzed - Analysis Complete
Use-After-Free in Linux Kernel SCTP Implementation

Publication date: 2026-05-28

Last updated on: 2026-06-10

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-28
Last Modified
2026-06-10
Generated
2026-06-17
AI Q&A
2026-05-28
EPSS Evaluated
2026-06-16
NVD
EUVD
Affected Vendors & Products
Showing 10 associated CPEs
Vendor Product Version / Range
linux linux_kernel 7.1
linux linux_kernel 7.1
linux linux_kernel 7.1
linux linux_kernel From 5.16 (inc) to 6.1.175 (exc)
linux linux_kernel From 5.11 (inc) to 5.15.209 (exc)
linux linux_kernel From 6.2 (inc) to 6.6.140 (exc)
linux linux_kernel From 6.13 (inc) to 6.18.32 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.90 (exc)
linux linux_kernel From 6.19 (inc) to 7.0.9 (exc)
linux linux_kernel From 4.17 (inc) to 5.10.258 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-416 The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's SCTP (Stream Control Transmission Protocol) implementation, specifically in the SCTP_SENDALL path within the sctp_sendmsg() function.

The issue arises because the function iterates over a list of associations using a cached pointer (@tmp) that may become stale if another thread modifies the list while the socket lock is temporarily dropped.

If the cached pointer becomes stale, it can lead to a use-after-free condition or type confusion, potentially causing incorrect memory access or controlled indirect calls.

The vulnerability is fixed by re-deriving the cached pointer after the function that may drop the lock returns, ensuring the pointer is still valid.

Impact Analysis

This vulnerability can lead to use-after-free or type confusion conditions in the Linux kernel's SCTP implementation.

Such conditions may allow an attacker to cause a kernel crash, leading to denial of service, or potentially execute arbitrary code with kernel privileges.

The vulnerability is reachable without elevated capabilities (CapEff=0), meaning an unprivileged user could exploit it.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-46227. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart