CVE-2026-46227Disclosure(linux / linux_kernel)

LOWCVSS 7.8 · HIGH

Signal is active with 1 mentions in latest observed window

Immediate actions

  • Track advisory updates for patch or workaround availability

Recommended action window: Monitor and triage in normal cycle

NVD 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.

0.0/ 10 priority

Sources & remediation

Weakness type (CWE)
CWE-416CWE-367

Priority

LOW

Exploitation

NONE

PoC

NONE

Patch

AVAILABLE

Momentum

NONE

Are you affected?

If you run products in this scope, you should treat this CVE as relevant to your environment.

  • linux_kernel

Threat summary

  • 1 mentions across 1 observed day

What's happening

  • Disclosure: 1 classified signal
  • 1 total mentions across 1 day

Affected systems

Vendors
Products
linux_kernel

1 version affected across 1 product

Deep dive

Activity timeline1 mentions / 1d
00111Mentions · 2026-05-28: 105-28
Signal classification1 categories
Disclosure
1100.0%
Referenced assets2 URLs
Full discourse1 post
  • Vulmon Vulnerability Feed@VulmonFeeds
    Disclosure

    CVE-2026-46227 In the Linux kernel, the following vulnerability has been resolve... https://vulmon.com/vulnerabilitydetails?qid=CVE-2026-46227 Customizable Vulnerability Alerts: https://alerts.vulmon.com/?utm_source=twitter&utm_medium=social&utm_campaign=2102281&utm_content=4

    Post summary

    The post announces that CVE‑2026‑46227, a Linux kernel vulnerability, has been resolved, providing a link to a vulnerability details page but no further technical, exploit, or patch information.

    0000054
    4.0K followersView on X
CPE platform detail4 entries

4 of 4 entries

PartVendorProductVersionTarget SWTarget HW
OSlinuxlinux_kernel---
OSlinuxlinux_kernel7.1--
OSlinuxlinux_kernel7.1--
OSlinuxlinux_kernel7.1--

Explore more