CVE-2026-46227: Linux Kernel Use-After-Free Vulnerability

CVE-2026-46227 Overview

CVE-2026-46227 is a Linux kernel vulnerability in the Stream Control Transmission Protocol (SCTP) subsystem. The flaw resides in the SCTP_SENDALL code path within sctp_sendmsg(), where the iterator macro list_for_each_entry_safe() caches the next association pointer before the loop body executes. When the socket lock is dropped inside sctp_wait_for_sndbuf(), a concurrent thread can peel off or free the cached association, leaving a stale pointer for the next iteration. The result is either a use-after-free or a type confusion that yields a controlled indirect call through outqueue.sched->init_sid.

Critical Impact

Local unprivileged attackers (CapEff=0) can trigger memory corruption and a controlled indirect call in kernel context, enabling potential local privilege escalation.

Affected Products

• Linux kernel SCTP subsystem (net/sctp/socket.c)
• Stable kernel branches patched via commits 1bfb06e, 6187a17, abb5f36, bf0f40d, and c9dadb3
• Distributions shipping unpatched kernels with SCTP enabled

Discovery Timeline

• 2026-05-28 - CVE-2026-46227 published to NVD
• 2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-46227

Vulnerability Analysis

The SCTP_SENDALL path iterates ep->asocs using list_for_each_entry_safe(), which pre-caches the next list entry in @tmp before invoking the loop body. The body calls sctp_sendmsg_to_asoc(), which can drop the socket lock inside sctp_wait_for_sndbuf() while waiting for buffer space.

While the lock is released, a second thread can invoke SCTP_SOCKOPT_PEELOFF on the association referenced by @tmp. The peeloff calls sctp_sock_migrate(), which performs list_del_init() followed by list_add_tail() onto a new endpoint's asocs list. If the new socket is then closed, the association is freed via kfree_rcu(). Alternatively, a network ABORT processed in softirq can free the cached association directly.

On re-lock, sctp_wait_for_sndbuf() revalidates @asoc through sk != asoc->base.sk and asoc->base.dead checks. However, @tmp is never revalidated. The next loop iteration advances onto a freed object or onto the head of a different endpoint's list, producing type confusion of &newep->asocs interpreted as a struct sctp_association *. Both outcomes are reachable without elevated capabilities.

Root Cause

The defect is a race condition combined with a stale iterator [CWE-416]. list_for_each_entry_safe() only protects against removal of the current node, not removal or migration of the cached next node when the lock is released mid-iteration.

Attack Vector

A local attacker opens an SCTP endpoint with multiple associations and issues a SCTP_SENDALL send that blocks in sctp_wait_for_sndbuf(). A second thread peels off the queued next association and closes the peeled socket, or aborts the association from the peer side. When the sender resumes, iteration follows a dangling pointer. The type-confused path provides controlled indirect call through outqueue.sched->init_sid, which adversaries can leverage for kernel control-flow hijacking.

See the upstream fix in Kernel Git Commit 1bfb06e, which re-derives @tmp from @asoc after sctp_sendmsg_to_asoc() returns.

Detection Methods for CVE-2026-46227

Indicators of Compromise

• Kernel oops or general protection fault logs referencing sctp_sendmsg, sctp_sendmsg_to_asoc, or sctp_wait_for_sndbuf in the call trace
• KASAN use-after-free reports against struct sctp_association allocations freed by kfree_rcu
• Unexpected process crashes or kernel panics on hosts exposing SCTP sockets to local users or containers

Detection Strategies

• Audit installed kernel versions against the patched stable releases referenced by commits 1bfb06e, 6187a17, abb5f36, bf0f40d, and c9dadb3
• Enable KASAN in test environments to catch use-after-free conditions in the SCTP path during fuzzing
• Monitor auditd or eBPF telemetry for unprivileged processes invoking setsockopt with SCTP_SOCKOPT_PEELOFF followed by rapid socket closure

Monitoring Recommendations

• Alert on kernel log entries containing BUG:, KASAN:, or general protection fault correlated with SCTP symbols
• Track creation of SCTP sockets by non-root users in container and multi-tenant environments
• Correlate kernel crash telemetry with workload identity to identify exploitation attempts

How to Mitigate CVE-2026-46227

Immediate Actions Required

• Update to a Linux kernel build containing the upstream fix that re-derives @tmp from @asoc after sctp_sendmsg_to_asoc() returns
• Disable the SCTP module on systems that do not require it by blacklisting sctp in /etc/modprobe.d/
• Restrict the creation of SCTP sockets by unprivileged users and containers through seccomp or LSM policies

Patch Information

The fix is committed upstream and backported through the stable tree. Review the patches at Kernel Git Commit 1bfb06e, Kernel Git Commit 6187a17, Kernel Git Commit abb5f36, Kernel Git Commit bf0f40d, and Kernel Git Commit c9dadb3. Apply the vendor kernel update appropriate for your distribution.

Workarounds

• Blacklist the SCTP kernel module where it is not required for application traffic
• Apply seccomp filters to block socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP) calls from untrusted workloads
• Restrict user namespaces in container runtimes to limit access to the SCTP socket family

# Configuration example: disable the SCTP module
echo "blacklist sctp" | sudo tee /etc/modprobe.d/disable-sctp.conf
echo "install sctp /bin/true" | sudo tee -a /etc/modprobe.d/disable-sctp.conf
sudo rmmod sctp 2>/dev/null || true