LiveActive security incident?Get immediate response
CVE Record

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.

HighCVSS 7.8Not KEV-listedUpdated
Glexia's TakeAutomated analysishigh

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.
Prepared
Confidence
high
Sources
12

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.

Open ATT&CK lookup
cve · low confidence lookup

CVE-2026-46227 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
High
CVSS
7.8 (3.1)
Known Exploited
No
Published

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

ScoreVersionSeverityVectorExploitImpactSource
7.8CVSS 3.1HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H1.85.9Linux
7CVSS 3.1HighCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H15.9redhat-SADP

Vulnerability scoring details

Base CVSS 3.1 score

7.8High
CVSS 3.1 vector shape for CVE-2026-46227Attack VectorAttack ComplexityPrivileges RequiredUser InteractionScopeConfidentiality ImpactIntegrity ImpactAvailability Impact

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Attack Vector
NetworkAdjacentLocalPhysical
Attack Complexity
LowHigh
Privileges Required
NoneLowHigh
User Interaction
NoneRequired
Scope
ChangedUnchanged
Confidentiality Impact
HighLowNone
Integrity Impact
HighLowNone
Availability Impact
HighLowNone

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. ADP timelineredhat-SADP

    Reported to Red Hat.

  3. ADP timelineredhat-SADP

    Made public.

  4. CVE publishedCVE Program

    The CVE record was published.

  5. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

redhat-SADPkernel: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL
other:Red Hat severity ratingcvssV3_1
  • 2026-05-28T00:00:00.000Z: Reported to Red Hat.
  • 2026-05-28T00:00:00.000Z: Made public.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux4910280503f3af2857d5aa77e35b22d93a8960a8, 4910280503f3af2857d5aa77e35b22d93a8960a8, 4910280503f3af2857d5aa77e35b22d93a8960a8, 4910280503f3af2857d5aa77e35b22d93a8960a8, 4910280503f3af2857d5aa77e35b22d93a8960a8, 4910280503f3af2857d5aa77e35b22d93a8960a8, 4910280503f3af2857d5aa77e35b22d93a8960a8, 4910280503f3af2857d5aa77e35b22d93a8960a8unaffected
LinuxLinux4.17, 0, 5.10.258, 5.15.209, 6.1.175, 6.6.140, 6.12.90, 6.18.32, 7.0.9, 7.1affected
Weakness

CWE details

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.