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.
HarborGuard Analysis
HarborGuard analysisSynopsis
A use-after-free and type-confusion vulnerability exists in the Linux kernel's SCTP networking subsystem, specifically in the SCTP_SENDALL message path. An attacker with a local shell and a low-privilege account can trigger the bug by racing a SCTP_SOCKOPT_PEELOFF or ABORT against a concurrent sendmsg loop, causing the kernel to dereference a freed association pointer or walk onto a misidentified list structure. Successful exploitation gives the attacker full read, write, and execution control at the kernel level. A patched-image rebuild at the fix versions (6.6.140, 6.12.90, 6.18.32, and the upstream commit 1bfb06ecb00f) is available on HarborGuard for affected environments.
HarborGuard Coverage
Detection is available across every HarborGuard environment: the CVE is ingested from upstream kernel security feeds within minutes of publication and matched against all customer images, including custom-built images that carry a vulnerable kernel version. Any image whose kernel package falls below the fix versions is flagged immediately.
AvailableHarborGuard scores this finding at CVSS 7.8 HIGH and can weight it further against each customer environment's compliance policy, for example elevating priority for images running privileged or host-network containers. Triage results are routed to the appropriate team inbox within each customer org based on configured ownership rules.
AvailableA patched-image rebuild at the fixed kernel versions (6.6.140, 6.12.90, 6.18.32, or the equivalent upstream commit) is available for environments running an affected kernel. For customers who opt into auto-remediation, HarborGuard triggers a rebuild, runs a regression test suite against the new image, and opens a pull request against affected workloads.
AvailableExploit Conditions
- Network reachabilityNot required
The attacker needs an existing shell or process on the host; no network access to the target is required to trigger the vulnerable code path.
- AuthenticationRequired
Any low-privilege local account is sufficient; no administrative or elevated credentials are needed to reach the vulnerable SCTP socket operations.
- Victim interactionNot required
Exploitation is fully attacker-driven; no action by another user or process is required beyond normal kernel scheduling of concurrent threads.
- Attack complexityDetail
While a race condition is involved, the CVE description notes that both exploitation paths are reachable from CapEff=0, and the CVSS AC:L rating indicates the exploit is considered reliable and does not depend on uncommon environmental preconditions.
Blast Radius
- The attacker gains kernel-level code execution via a controlled indirect call through the SCTP outqueue scheduler pointer exposed by the type-confusion path.
- Confidentiality impact is complete: all kernel memory, including credentials, session tokens, and data belonging to other processes, is readable.
- Integrity impact is complete: the attacker can modify any in-memory kernel structure, persisted files, or process state on the host.
- Availability impact is complete: the attacker can crash the host or permanently disable affected network services.
How HarborGuard Handles This
Available on HarborGuard: any image carrying a Linux kernel below 6.6.140, 6.12.90, or 6.18.32 (or lacking the upstream fix commit 1bfb06ecb00f) is flagged as soon as the CVE is ingested. Where compliance policy permits, HarborGuard can trigger an automated rebuild of the image at a fixed kernel version, run a regression test suite, and open a pull request against affected workloads. For high-severity findings like this one, the median time from CVE publication to a merged patch PR is around 90 minutes for environments with auto-remediation enabled. Given the local privilege-escalation nature of this bug, customers who cannot immediately rebuild are encouraged to apply network-policy isolation to restrict SCTP socket access to trusted workloads, enforce seccomp or AppArmor profiles that block CAP_NET_RAW and raw socket creation where not needed, and review whether SCTP is required in their environment at all, since disabling the kernel module eliminates the attack surface entirely.
Metrics
- CVSS v3.1
- 7.8
- Severity
- HIGH
- Fixed in
- 0
- Affected Products
- 2
Fix available
- Linux / Linux< 1bfb06ecb00f7fdf35dba8e8f2877346cbe5e078 (from 4910280503f3af2857d5aa77e35b22d93a8960a8) · < 6187a172d6ed57d6b2c327836e4407c6456e639d (from 4910280503f3af2857d5aa77e35b22d93a8960a8) · < c9dadb31f36045a8cb65df4bd75e7237ef21a4b5 (from 4910280503f3af2857d5aa77e35b22d93a8960a8) · < bf0f40d8107e2ce827521968dc6926f3e13728ae (from 4910280503f3af2857d5aa77e35b22d93a8960a8) · < abb5f36771cc4c05899b34000829a787572a8817 (from 4910280503f3af2857d5aa77e35b22d93a8960a8)
- Linux / Linux4.17Fixed in 0, 6.6.140, 6.12.90, 6.18.32, 7.0.9, 7.1-rc4
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H