CVE-2026-63971: Linux Kernel SCTP Race Condition Flaw

CVE-2026-63971 Overview

CVE-2026-63971 is a race condition in the Linux kernel's Stream Control Transmission Protocol (SCTP) implementation. The flaw exists in sctp_wait_for_connect(), which drops and re-acquires the socket lock while waiting for an association to reach the ESTABLISHED state. During this window, a concurrent thread can peel off the association to a new socket via getsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc->base.sk. The original waiter then resumes and returns success without detecting the migration, causing sctp_datamsg_from_user() to access the association under the wrong lock.

Critical Impact
A local unprivileged attacker can trigger memory corruption or kernel state inconsistency by racing SCTP connect and peeloff operations, potentially escalating privileges on affected Linux systems.

Affected Products

Linux kernel SCTP subsystem (net/sctp)
Multiple stable kernel branches referenced in the upstream commits
Distributions shipping vulnerable kernel versions prior to the referenced fixes

Discovery Timeline

2026-07-19 - CVE-2026-63971 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-63971

Vulnerability Analysis

The vulnerability is a race condition [Race Condition / TOCTOU class] in the SCTP socket layer. When a user calls sendmsg() on an SCTP socket before the association reaches ESTABLISHED, the kernel invokes sctp_wait_for_connect(). This function releases the socket lock, sleeps on a wait queue, and re-acquires the lock upon wakeup.

While the lock is released, another thread holding a reference to the same association can invoke getsockopt(SCTP_SOCKOPT_PEELOFF). Peeloff migrates the association to a newly created socket and reassigns asoc->base.sk to point at that new socket. When the original caller wakes, it re-acquires the original socket lock, not the new one now owning the association.

The caller then returns to sctp_datamsg_from_user() and continues operating on asoc under a lock that no longer protects it. This produces unsynchronized access to association state, breaking the locking invariants relied on by subsequent send-path code and creating exploitable memory safety conditions.

Root Cause

sctp_wait_for_connect() did not re-validate that sk == asoc->base.sk after re-acquiring the socket lock. The related helper sctp_wait_for_sndbuf() already performs this check, but the connect wait path did not. The fix adds the same sk != asoc->base.sk verification and returns an error when the association was migrated during the sleep.

Attack Vector

Exploitation requires local access and the ability to open SCTP sockets. An attacker runs two threads sharing an SCTP association: one thread issues sendmsg() on a not-yet-established association to force sctp_wait_for_connect() to block, and a second thread issues getsockopt(SCTP_SOCKOPT_PEELOFF) to migrate the association. Winning the race yields kernel state accessed under an incorrect lock, which can be leveraged for use-after-free or privilege escalation.

No verified public proof-of-concept code is available. Refer to the upstream fix commits for the precise code paths, including kernel commit f14fe6395a8b and kernel commit 8e9b56051d24.

Detection Methods for CVE-2026-63971

Indicators of Compromise

Unexpected kernel oops, BUG: messages, or lockdep splats referencing sctp_wait_for_connect, sctp_datamsg_from_user, or sctp_do_peeloff.
KASAN reports of use-after-free or invalid access within the net/sctp/socket.c code path.
Unprivileged processes creating SCTP sockets and issuing rapid SCTP_SOCKOPT_PEELOFF calls in tight loops.

Detection Strategies

Audit kernel versions across the fleet and compare against the patched builds referenced in the upstream stable commits.
Enable kernel lockdep and KASAN in test environments to catch the race and any regressions.
Alert on process behavior that combines multi-threaded SCTP sendmsg() with concurrent SCTP_SOCKOPT_PEELOFF usage, which is uncommon in normal workloads.

Monitoring Recommendations

Collect dmesg and /var/log/kern.log centrally and search for SCTP-related warnings, oopses, or KASAN traces.
Track loading of the sctp kernel module on hosts that do not require SCTP; unexpected loads warrant investigation.
Monitor local privilege boundary crossings and unexpected root-owned processes spawned from users with SCTP socket access.

How to Mitigate CVE-2026-63971

Immediate Actions Required

Apply the vendor-provided kernel updates that incorporate the upstream SCTP fix commits as soon as they are available for your distribution.
If patching is delayed, blacklist the sctp kernel module on hosts that do not require SCTP connectivity.
Restrict which users can create raw or protocol-specific sockets using seccomp, AppArmor, or SELinux policies.

Patch Information

The fix adds an sk != asoc->base.sk check in sctp_wait_for_connect(), mirroring the existing check in sctp_wait_for_sndbuf(), and returns an error when the association has been migrated during the wait. The fix is distributed across multiple stable branches, including commit 0e0d5bc76fd4, commit 6140cfa72145, commit 634a9af8a26a, commit 68667ee4c7da, commit 7d2038d4b801, commit 8e9b56051d24, commit bcfeac79af74, and commit f14fe6395a8b.

Workarounds

Disable the SCTP module where not required by adding install sctp /bin/true to a modprobe configuration file.
Prevent unprivileged loading of the module by setting /proc/sys/kernel/modules_disabled to 1 on hardened systems after boot.
Constrain SCTP usage to trusted service accounts and containers via seccomp filters that block the SCTP_SOCKOPT_PEELOFFgetsockopt call.

bash

# Configuration example: blacklist the SCTP kernel module
echo 'install sctp /bin/true' | sudo tee /etc/modprobe.d/disable-sctp.conf
sudo rmmod sctp 2>/dev/null || true
lsmod | grep -w sctp || echo 'sctp module not loaded'