Eighteen years is a long time for a flaw to sit quietly inside the heart of the Linux kernel. Yet that is exactly how long a use-after-free bug in the SCTP networking stack has survived, hiding in the code since Linux 2.6.25 shipped in 2008. Tracked as CVE-2026-64564 and publicly named "SCTPhantom", the vulnerability turns a low-privilege local account into full root on the host — and, in container environments, it allows an attacker to break out and reach the machine underneath.
Researchers from Tencent's team, working through the Corvus AI initiative, converted the initial finding into a fully reproducible exploit chain. Their write-up demonstrates that the bug is deterministic: it requires only local access, low privileges, and no user interaction. For operators running SCTP-enabled kernels, this is a patch-this-week situation, not a patch-when-convenient one.
What Is SCTP and Why Should You Care?
The Stream Control Transmission Protocol (SCTP) is a message-oriented transport protocol standardized by the IETF in RFC 4960. Unlike TCP's strict byte-stream model, SCTP supports multi-streaming and multi-homing — the ability to maintain multiple IP paths within a single association. That multi-homing design is precisely what makes SCTP valuable for telecom infrastructure (signaling over SS7/SIGTRAN), mobile networks, and high-availability clusters where a single IP failure should not tear down a connection.
Because SCTP is baked into the Linux kernel as a first-class protocol (socket type SOCK_SEQPACKET via sctp sockets), every distribution that ships the SCTP module inherits this defect. Even hosts that do not actively use SCTP for application traffic can be vulnerable if the sctp kernel module is loadable and reachable on the target.
The Root Cause: An Identity Mix-Up in ASCONF
The flaw lives inside Dynamic Address Reconfiguration (ASCONF), the kernel feature that lets endpoints change the set of IP addresses bound to an active SCTP association without re-establishing it. The vulnerable logic is in sctp_process_asconf(), which caches the transport that the ASCONF chunk is processed against in asconf->transport.
The core problem is an inconsistency between two addresses. The kernel validates a "delete IP" (DEL-IP) operation by checking it against the packet's source address — a guard defined as ADDIP D8 / SCTP_ERROR_DEL_SRC_IP. But when it actually acts on the request, it operates on a transport it selected using a different address carried inside the message itself.
That leaves a dangerous gap. A single ASCONF message can deliver the following ordered sequence:
[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]Here, address L deliberately differs from the packet's source address. The DEL-IP L request sails through the D8 source-address check and invokes sctp_assoc_rm_peer() on the very transport that asconf->transport still points to — freeing it (RCU-deferred). The trailing wildcard delete (0.0.0.0) then reuses the now-dangling pointer in sctp_assoc_set_primary(), preserving the freed transport inside the association's primary_path and active_path pointers.
The result is a textbook use-after-free: the connection keeps referencing memory the kernel has already released. A later socket operation dereferences that stale pointer, and the attacker controls the fallout.
From a Dangling Pointer to Global Root: The Exploit Chain
Raw memory corruption is one thing; turning it into root is another. The Tencent team's chain is notable precisely because it avoids the two most common exploit appendages — no shellcode and no traditional Return-Oriented Programming (ROP) chain. Instead, the exploit builds a fake kernel object graph:
- Heap grooming: The freed transport object is reclaimed using a packet socket ring buffer, letting the attacker control the contents of the freed memory.
- KASLR defeat: The reclaimed object leaks a kernel heap address, which enables a repeatable four-byte kernel read. The researchers used this read to inspect the Interrupt Descriptor Table (IDT) and defeat Kernel Address Space Layout Randomization.
- Second use-after-free: A second use-after-free is triggered using attacker-controlled SCTP authentication key data, allowing the attacker to lay out a counterfeit kernel object structure.
- Privilege escalation: The fake object graph eventually reaches
commit_creds(), swapping the attacker's credentials with root — cleanly, and without executing a single byte of shellcode.
The chain was validated across a wide spread of environments: Ubuntu 24.04, Debian 13, Rocky Linux 9 (RHEL 9-family kernels), and multiple builds ranging from 5.14 up to a 7.2 release candidate. In every tested case, the exploit achieved root. On container hosts, that root on a containerized process translated into host-level root — a full container escape.
Why DoS Is the Fallback Scenario
Not every attacker needs root. Because the trigger is a kernel crash, the same bug doubles as an availability weapon. A malformed ASCONF sequence can free a transport the association still believes is live, and the ensuing dereference of freed memory can take the entire host down. In environments where SCTP peers are reachable over the network, this capability turns a diagnostic feature into a remote denial-of-service vector, even when full privilege escalation is not possible.
This dual personality — LPE up to root, or network-triggered DoS — is why CVE-2026-64564 earned urgent attention from distro maintainers rather than routine triage.
Scope and Real-World Exposure
It is important to keep the attack surface in perspective. SCTPhantom is a local flaw, not a remote one: it requires SCTP to be loadable and reachable on the target, and the escalation path needs local code execution at a low privilege level. That limits what network-facing attackers without a foothold can do directly. However, it dramatically expands what an already-compromised process can achieve — the classic local privilege escalation problem, plus the container-escape angle that makes it dangerous on multi-tenant and CI/CD infrastructure.
The Tencent team also documented an interesting nuance regarding capabilities. An earlier iteration of the exploit required the net.sctp.addip_enable and net.sctp.addip_noauth_enable sysctls to be enabled, which made CAP_NET_ADMIN look like a prerequisite. They later discovered a route that leaves both sysctls untouched, enabling the needed features per-socket instead — removing even that obstacle from the threat model.
Fixes and Mitigation
The upstream fix — commit 9b2854f86f0b — addresses the root cause directly: "sctp: don't free the ASCONF's own transport in DEL-IP processing." The patch rejects any DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard. With that guard in place, the wildcard branch can never reuse a freed transport. Stable releases carrying the fix include:
- 6.6.148 and later
- 6.12.101 and later
- 6.18.42 and later
- 7.1.6 and 7.2-rc5
Vendor kernels may ship backports on older longterm base versions, so check your distribution's changelog for the relevant branch. Until patched, defenders should:
- Harden SCTP exposure: block protocol 132 at the firewall where SCTP is not required for legitimate traffic.
- Disable the module:
modprobe -r sctpor blacklist it withblacklist sctpin/etc/modprobe.d/if the service does not need it. - Restrict local privileges: assume any low-privilege local account is a potential root escalation path until the kernel is updated.
- Monitor container hosts: treat container breakout as a plausible outcome on unpatched SCTP hosts, and enforce capability restrictions at the runtime level.
- Apply the distro kernel update promptly — this is a deterministic local-to-root primitive, not a probabilistic one.
An eighteen-year-old flaw in a protocol most sysadmins rarely think about is a sharp reminder that the surface area of a modern kernel is enormous. SCTP's multi-homing elegance bought real resilience at the cost of deeply nested state machines — and every one of those transitions is a potential landmine. SCTPhantom is patched upstream, but the patching only works if administrators actually deploy it. On SCTP-enabled hosts, today is the day to reboot into a fixed kernel.
Technical sources: Tencent Matrix write-up, The Hacker News, Rapid7 Vulnerability Database, and the Linux kernel ASCONF advisory referenced herein.
Follow KryptNix for in-depth Linux security analysis, kernel vulnerability breakdowns, and practical hardening guides.