CVE-2026-63971

What it actually does

This is a local Linux kernel race condition in SCTP socket handling. While sctp_wait_for_connect() temporarily releases and re-acquires a socket lock, another local thread can peel off the SCTP association to a different socket using SCTP_SOCKOPT_PEELOFF. The original code can then continue operating on the association under the wrong socket lock in sctp_datamsg_from_user(). That creates unsafe concurrent access to kernel SCTP association state and may lead to kernel memory corruption, information disclosure, privilege escalation, or system crash. The vulnerability requires local code execution or equivalent ability to create and manipulate SCTP sockets; it is not described as remotely exploitable by sending network traffic alone.

Why it matters to the business

Successful exploitation could let a low-privileged local user or compromised workload destabilize a Linux host or potentially gain elevated privileges. The most immediate operational risk is denial of service through kernel crashes or panics; the higher-impact risk is container or user-to-root escalation on systems where untrusted users, shared hosting workloads, CI jobs, or containers can access SCTP-capable kernels. EPSS is currently very low and there is no known CISA KEV listing or public exploit maturity reported, but kernel local privilege escalation issues should still be prioritized on multi-user and containerized systems.

How an attack unfolds

An attacker first obtains the ability to run local code on a vulnerable Linux system. They create SCTP sockets and drive an association into a state where one thread waits in sctp_wait_for_connect() for the association to become established. During the window where that function has dropped the original socket lock, a second attacker-controlled thread uses SCTP_SOCKOPT_PEELOFF to move the association to a new socket. When the first thread resumes, the vulnerable kernel path may fail to notice that the association’s owning socket changed and proceed to send user data through sctp_datamsg_from_user() while holding the wrong lock. By repeatedly winning this race, an attacker may trigger memory safety side effects, kernel warnings, crashes, or potentially shape corruption into privilege escalation depending on kernel build, hardening, timing, and SCTP configuration.

How to fix it

Apply the vendor-provided Linux kernel update that includes the SCTP fix adding validation that the association’s socket has not changed after sctp_wait_for_connect() re-acquires the lock. Because no product-specific fixed versions were provided, use distribution kernel advisories and package changelogs to identify the first kernel build containing the upstream SCTP race fix for this CVE. Reboot into the patched kernel after installation; updating packages without rebooting does not remove exposure for the running kernel. If SCTP is not required, reduce attack surface by disabling or blocking SCTP where operationally safe, for example by preventing the sctp kernel module from loading and filtering SCTP protocol traffic. On systems that run untrusted local code, also consider hardening measures such as restricting unprivileged user namespaces, limiting container capabilities, applying seccomp profiles that block SCTP socket creation where not needed, and ensuring kernel lockdown/hardening features are enabled.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is patched. Validate with uname -r, distribution package metadata, and vendor security advisories for the exact kernel build. Where source or debug symbols are available, confirm that sctp_wait_for_connect() checks whether sk != asoc->base.sk after re-acquiring the lock and returns an error if the association migrated. Verify SCTP exposure by checking whether the sctp module is loaded, whether SCTP sockets can be created by unprivileged users, and whether workloads require IPPROTO_SCTP. If SCTP has been disabled as a mitigation, confirm that modprobe cannot load sctp and that attempts to create SCTP sockets fail. For fleet validation, prioritize shared compute, container hosts, bastion hosts, CI runners, and systems allowing non-admin shell access.

Typical attack path

1. Gain local code execution as an unprivileged user or inside a workload/container with access to SCTP socket creation.
2. Create SCTP socket associations and arrange for a connect/send path that waits for the association to reach ESTABLISHED state.
3. Run a competing thread that invokes SCTP_SOCKOPT_PEELOFF against the same association while the connect wait path has temporarily released the socket lock.
4. Cause the original thread to resume and operate on the migrated association under the stale/wrong socket lock.
5. Repeat the race to trigger kernel memory corruption, kernel oops/panic, denial of service, or potential privilege escalation.

How to detect it

Post-exploitation detection is difficult because successful exploitation may leave no clean application-level artifact; evidence is most likely in kernel logs, crash dumps, audit telemetry, and syscall tracing. Review journalctl, dmesg, /var/log/kern.log, /var/log/messages, crash dump directories, kdump/vmcore artifacts, and EDR/eBPF telemetry for SCTP-related kernel faults. Look for kernel oops, panic, KASAN, lockdep, use-after-free, NULL pointer dereference, general protection fault, or slab corruption messages with stack traces referencing SCTP functions such as sctp_wait_for_connect(), sctp_datamsg_from_user(), sctp_do_peeloff(), or files under net/sctp/. On systems with auditd, eBPF, or syscall monitoring, hunt for unusual local processes creating SCTP sockets, repeated AF_INET/AF_INET6 IPPROTO_SCTP socket calls, and getsockopt calls using SCTP_SOCKOPT_PEELOFF. Correlate suspicious SCTP activity with process ancestry, container IDs, user sessions, privilege changes, crashes, and unexpected reboots. Absence of these artifacts does not prove non-exploitation, especially if logs rotated or the host crashed before writing telemetry.

• sctp_wait_for_connect
• sctp_datamsg_from_user
• sctp_do_peeloff
• SCTP_SOCKOPT_PEELOFF
• IPPROTO_SCTP
• AF_INET SOCK_SEQPACKET IPPROTO_SCTP
• AF_INET6 SOCK_SEQPACKET IPPROTO_SCTP
• net/sctp/
• kernel BUG at net/sctp
• BUG: KASAN
• KASAN: use-after-free
• general protection fault
• unable to handle kernel NULL pointer dereference
• kernel panic
• Oops:
• sctp:

What your security team should do

• Patch and reboot Linux systems running vulnerable kernels, prioritizing multi-user servers, container hosts, CI/build infrastructure, shared hosting, and systems where untrusted users can execute code.
• If SCTP is not business-critical, disable the sctp kernel module and enforce controls that prevent SCTP socket creation by untrusted workloads.
• Add audit or eBPF-based monitoring for unusual SCTP socket creation and SCTP_SOCKOPT_PEELOFF usage on high-risk Linux hosts.
• Review recent kernel oops, panic, KASAN, and general protection fault logs for SCTP-related stack traces, especially involving sctp_wait_for_connect, sctp_datamsg_from_user, or SCTP peeloff operations.
• Confirm all remediation checks use the running kernel version after reboot, not only package inventory.
• Track distribution advisories because fixed kernel versions vary by vendor and backport level; do not rely solely on upstream version comparisons.