CVE-2026-46227: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL
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.
Security readout for executives and security teams
Plain-English summary
CVE-2026-46227 is a Linux kernel SCTP bug that can let a local low-privileged user crash the system or potentially gain stronger control. The risk is highest on multi-user hosts, container platforms, and systems where SCTP is enabled or used. The source bundle names Linux stable fixes and Red Hat advisories, but does not show active exploitation.
Executive priority
Patch on the next urgent kernel maintenance cycle, sooner for shared or multi-tenant Linux infrastructure. The issue is local, but the impact can be severe and the source indicates low-privilege reachability.
Technical view
The SCTP_SENDALL path reuses a cached association-list cursor after sctp_sendmsg_to_asoc() may drop and regain the socket lock. Another thread can migrate or free the cached association, causing use-after-free or list type confusion. The CVE is CWE-367 with CVSS 7.8, local low-privilege attack, no user interaction, and high CIA impact.
Likely exposure
Linux systems running affected kernel builds are in scope, especially where local users, containers, or workloads can reach SCTP socket behavior. Exact exposure depends on kernel version, distribution backports, and whether the relevant SCTP functionality is enabled or usable.
Exploitation context
The source states reachability from CapEff=0 and describes memory corruption outcomes. CISA KEV is false in the bundle, and no provided source confirms active exploitation. Treat this as a serious local privilege or availability risk, not a confirmed internet-exploited issue.
Researcher notes
Focus analysis on SCTP_SENDALL list iteration, lock dropping in sctp_wait_for_sndbuf(), and stale tmp cursor handling. The fix re-derives tmp from the validated current association after return. Evidence supports memory-safety impact, but source data does not include public exploit confirmation.
Mitigation direction
Apply Linux stable or distribution kernel updates containing the referenced fixes.
Use Red Hat RHSA advisories where applicable to identify fixed packages.
Prioritize shared Linux hosts, container nodes, and systems with untrusted local users.
Review whether SCTP is required; disable unused SCTP exposure per vendor guidance.
Monitor vendor advisories for affected-version clarifications and backported fixes.
Validation and detection
Inventory running kernels and compare them with vendor CVE guidance.
Confirm whether SCTP is enabled, loaded, or required on affected systems.
Verify patched kernels include the relevant stable fix or vendor erratum.
Check Red Hat CVE and RHSA pages for product-specific status.
Run normal workload regression testing after kernel updates.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-367: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
5Timeline events
1ADP providers
24Source links
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-367 · source CWE mapping
Time-of-check Time-of-use (TOCTOU) Race Condition
Time-of-check Time-of-use (TOCTOU) Race Condition represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.