CVE-2026-46227: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL

Published May 28, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

sctp: revalidate list cursor after sctpsendmsgtoasoc() in SCTPSENDALL

The SCTPSENDALL path in sctpsendmsg() iterates ep->asocs with listforeachentrysafe(), which caches the next entry in @tmp before the loop body runs. The body calls sctpsendmsgtoasoc(), which may drop the socket lock inside sctpwaitforsndbuf().

While the lock is dropped, another thread can SCTPSOCKOPTPEELOFF the association cached in @tmp, migrating it to a new endpoint via sctpsockmigrate() (listdelinit() + listaddtail() to newep->asocs), and optionally close the new socket which frees the association via kfreercu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped.

sctpwaitforsndbuf() 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 sctpassociation ).

Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->initsid pointer.

Fix by re-deriving @tmp from @asoc after sctpsendmsgtoasoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that listdel an association from ep->asocs are sctpassociationfree() (which sets asoc->base.dead) and sctpassocmigrate() (which changes asoc->base.sk), and sctpwaitforsndbuf() 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 SCTPABORT path in sctpsendmsgchecksflags() returns 0 and the loop hits 'continue' before sctpsendmsgtoasoc() is ever called, so the @tmp cached by listforeachentrysafe() still covers the lock-held free that ba59fb027307 ("sctp: walk the list of asoc safely") was added for.

Affected Software

12 affected componentsFixes available
Linux Linux kernel
Linux Linux kernel>=4.17<5.10.258
Linux Linux kernel>=5.11<5.15.209
Linux Linux kernel>=5.16<6.1.175
Linux Linux kernel>=6.2<6.6.140
Linux Linux kernel>=6.7<6.12.90
Linux Linux kernel>=6.13<6.18.32
Linux Linux kernel>=6.19<7.0.9
Linux Linux kernel=7.1-rc1
Linux Linux kernel=7.1-rc2
Linux Linux kernel=7.1-rc3
Microsoft azl3 kernel 6.6.139.1-1<6.6.141.1-1
6.6.141.1-1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 6.6.141.1-1
  2. Upgrade

    Upgrade Linux kernel (SCTP) to a version that resolves this vulnerability.

    Patch ba59fb027307

Event History

May 28, 2026
CVE Published
via MITRE·09:40 AM
Data Sourced
via MITRE·09:40 AM
DescriptionSeverity
Data Sourced
via NVD·10:16 AM
RemedyDescriptionSeverityWeaknessAffected Software
Data Sourced
via Red Hat·11:03 AM
DescriptionSeverityAffected Software
May 29, 2026
Data Sourced
via Microsoft·08:07 AM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-46227?

The severity of CVE-2026-46227 is high, with a CVSS score of 7.8.

2

How do I fix CVE-2026-46227?

To fix CVE-2026-46227, update the Linux kernel to a version that includes the patch for this vulnerability.

3

What are the potential impacts of CVE-2026-46227?

CVE-2026-46227 may allow for potential remote code execution due to a use after free vulnerability in the SCTP protocol.

4

Is my system vulnerable to CVE-2026-46227?

Systems running affected versions of the Linux kernel and using SCTP may be vulnerable to CVE-2026-46227.

5

When was CVE-2026-46227 published?

CVE-2026-46227 was published on May 28, 2026.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203