CVE-2026-46227

What it actually does

CVE-2026-46227 is a Linux kernel SCTP use-after-free/type-confusion vulnerability in the SCTP_SENDALL path of sctp_sendmsg(). The kernel iterates an endpoint association list while caching the next list element; during sctp_sendmsg_to_asoc(), the socket lock can be dropped while waiting for send buffer space. A concurrent thread or network-triggered SCTP ABORT can migrate or free the cached association before iteration resumes. When the loop advances to the stale cached pointer, the kernel may dereference freed memory or interpret another endpoint list head as a struct sctp_association. The described type-confusion path can lead to a controlled indirect call through SCTP scheduling structures, making local privilege escalation or kernel code execution plausible. Successful exploitation can compromise confidentiality, integrity, and availability of the affected host.

Why it matters to the business

A local user or process with access to SCTP socket functionality could potentially escalate privileges to kernel level, crash the system, or take full control of a Linux host. This is most relevant for multi-user systems, container hosts, build infrastructure, shared compute platforms, appliances, and servers where untrusted or low-privileged code can run. Although the CVSS score is high, EPSS is currently very low and there is no known CISA KEV listing or public exploit maturity reported, so remediation should be prioritized through normal kernel patching processes unless SCTP is enabled and exposed to untrusted local workloads.

How an attack unfolds

An attacker first obtains the ability to execute local, low-privileged code on a vulnerable Linux system. They create SCTP sockets and associations, then trigger SCTP_SENDALL so the kernel enters the vulnerable sctp_sendmsg() association-list iteration. The attacker manipulates timing so sctp_sendmsg_to_asoc() drops the socket lock while waiting for send buffer space. While the lock is released, another thread peels off, migrates, closes, or otherwise causes an association cached as the next list entry to be freed or moved; alternatively, a network SCTP ABORT can free the cached association in softirq context. When the original send path reacquires the lock, it validates only the current association and not the cached next pointer. Iteration then advances to stale memory or to a misinterpreted list head, producing use-after-free or type confusion. With heap grooming and control over relevant SCTP structures, the attacker may redirect an indirect kernel call, leading to kernel crash or privilege escalation.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the SCTP SENDALL iterator revalidation issue. Because no exact fixed package versions were provided, use the kernel updates from the relevant Linux distribution or vendor advisory that reference this CVE or the SCTP fix that re-derives the iterator cursor after sctp_sendmsg_to_asoc(). Reboot into the patched kernel after installation; live patching should only be considered sufficient if the vendor explicitly states that this SCTP fix is covered. If immediate patching is not possible, reduce exposure by disabling SCTP where it is not required, preventing automatic loading of the sctp module, and restricting local untrusted code execution. Common mitigations include blacklisting the sctp kernel module, removing CAP_NET_RAW/CAP_NET_ADMIN-like capabilities from untrusted workloads where applicable, tightening container seccomp/AppArmor/SELinux profiles to block SCTP socket creation, and limiting access to multi-tenant shell or build environments.

How to confirm the fix worked

Confirm that systems are running a vendor kernel build that includes the fix for this SCTP vulnerability, not merely that an updated package is installed. Validate with uname -a and the distribution package manager, then compare the running kernel release against the vendor advisory. If SCTP is not required, verify that the sctp module is not loaded with lsmod and cannot be loaded due to modprobe blacklist or install rules. Test whether unprivileged users or containers can create SCTP sockets; attempts should fail if SCTP has been disabled or policy-blocked. Where source-level validation is possible, confirm that the SCTP_SENDALL loop re-derives the next association after sctp_sendmsg_to_asoc() returns rather than trusting a cached list cursor across a lock drop.

Typical attack path

1. Gain local code execution as an unprivileged user or process on a vulnerable Linux host.
2. Confirm SCTP support is available and the sctp kernel module or built-in SCTP stack can be used.
3. Create SCTP endpoints and associations suitable for SCTP_SENDALL behavior.
4. Drive send-buffer pressure so sctp_sendmsg_to_asoc() enters sctp_wait_for_sndbuf() and temporarily drops the socket lock.
5. Race a concurrent SCTP_SOCKOPT_PEELOFF, socket close, association migration, or SCTP ABORT against the SENDALL iteration.
6. Cause the cached next association pointer to reference freed or migrated memory.
7. Allow the original iterator to resume and dereference the stale pointer, triggering use-after-free or type confusion.
8. Use heap grooming and corrupted SCTP scheduling state to crash the kernel or attempt privilege escalation.

How to detect it

Look for signs of attempted local kernel exploitation involving SCTP socket operations, especially on systems where SCTP is not normally used. Relevant sources include kernel logs, journald, dmesg, auditd syscall telemetry, EDR process telemetry, container runtime logs, and crash dumps. Search for SCTP module loading, unusual local processes creating SCTP sockets, repeated SCTP peeloff operations, kernel oops/panic messages near SCTP functions, use-after-free reports from KASAN/KFENCE if enabled, and crashes with stack traces involving sctp_sendmsg(), sctp_sendmsg_to_asoc(), sctp_wait_for_sndbuf(), sctp_sock_migrate(), sctp_assoc_migrate(), or sctp_association_free(). Because successful exploitation may leave few durable artifacts beyond privilege escalation and kernel instability, correlate SCTP activity with unexpected root shells, setuid file changes, new kernel crash dumps, suspicious container escapes, or anomalous privilege changes. There are no known public exploit indicators or named threat actors reported for this CVE based on the supplied data.

• sctp_sendmsg
• sctp_sendmsg_to_asoc
• sctp_wait_for_sndbuf
• sctp_sock_migrate
• sctp_assoc_migrate
• sctp_association_free
• SCTP_SOCKOPT_PEELOFF
• SCTP_SENDALL
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG at net/sctp
• Oops:
• RIP: sctp_sendmsg
• RIP: sctp_sendmsg_to_asoc
• RIP: sctp_wait_for_sndbuf
• RIP: sctp_sock_migrate
• RIP: sctp_association_free
• sctp:
• modprobe sctp
• /proc/sys/net/sctp
• /sys/module/sctp

What your security team should do

• Inventory Linux systems where SCTP is enabled, the sctp module is loaded, or applications rely on SCTP.
• Prioritize patching multi-user hosts, container hosts, CI/CD workers, shared compute systems, internet-facing appliances, and systems that run untrusted local code.
• Apply vendor kernel updates that include the SCTP iterator revalidation fix and reboot into the patched kernel.
• If SCTP is not business-critical, disable or blacklist SCTP to reduce kernel attack surface.
• Restrict untrusted workloads from creating SCTP sockets using container runtime policy, seccomp, LSM controls, or capability reduction.
• Monitor for kernel warnings, crashes, SCTP-related faults, and suspicious local activity until patching is complete.
• Because this is not currently listed in CISA KEV and EPSS is low, track it as high-impact local privilege escalation risk rather than confirmed widespread exploitation.