SCTPhantom: an 18-year-old Linux bug that hands out root

Send a Linux machine three SCTP address-reconfiguration chunks in the right order and the kernel keeps using a pointer to memory it already freed. That is CVE-2026-64564, which Tencent's Zhuque Lab named SCTPhantom, and the end state is not a crash. It is root, and from inside a container it is the host underneath.

The flaw rates 8.5 on CVSS v4.0 and it is local rather than remote: an attacker needs an unprivileged shell and the ability to open an SCTP socket. On a shared build machine, a multi-tenant Kubernetes node, or any host that runs untrusted code in containers, that is a low bar. The offending logic landed in Linux 2.6.25 in December 2007, commit 42e30bf3463c. It sat in the most heavily audited codebase in open source for roughly eighteen years.

RelatedGhostLock: a 15-year Linux bug hands attackers root

What actually goes wrong?

SCTP supports multihoming. A live association can add, drop and reconfigure network paths on the fly through ASCONF chunks, defined in RFC 5061. Each path is a transport object inside the kernel.

The bug is an identity mismatch between two things the code treats as the same thing. When the kernel validates a DEL-IP request, it checks the address carried in the IP packet's source field. When it decides which transport to hold onto as the one servicing the ASCONF exchange, it uses the address parameter inside the chunk. Normally those match. An attacker can make them differ.

The attack is three chunks: an address parameter naming transport L, a DEL-IP for L, then a DEL-IP for the wildcard 0.0.0.0. The first deletion passes validation, because validation looks at the packet source and not at the cached pointer. The wildcard deletion then walks the transport list while that stale pointer is still installed. The association ends up with primary_path and active_path referencing freed memory, and the next socket operation that touches either one dereferences it.

The upstream fix is a single comparison. The kernel now refuses a deletion when the target is the transport it is holding for ASCONF processing: if (peer == asconf->transport) return SCTP_ERROR_REQ_REFUSED;. Eighteen years, one missing pointer check.

Why does a use-after-free become root?

A dangling pointer on its own is a denial of service. Turning it into privilege escalation took Zhuque Lab nine stages, and the write-up is unusually specific about them. The association is set up multihomed so the use-after-free survives rather than immediately panicking. The freed slot is reclaimed with pg_vec allocations, which leaks direct-map addresses. A controlled transport->asoc pointer then gives a four-byte kernel read, and reading interrupt descriptor table gate 0 defeats KASLR.

From there it is object-graph work: SCTP authentication-key allocations shape the heap, a forged address-family operations structure redirects a call into commit_creds(), and the process comes back with root credentials. A usermode-helper variant does the same trick against the host from inside a container.

The results are the part worth internalizing. The chain escalated on kernels spanning 5.14 through 6.12, and Zhuque reports root on stock builds of Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 and OpenCloudOS. In the container-escape scenario, six of eight attempts reached host root. That is not a fragile proof of concept.

Are you affected, and what do you patch?

Every maintained stable branch shipped a fix. Check your running kernel against the branch you are on, not against the mainline number.

If you cannot reboot into a patched kernel today, the practical mitigation is to stop the module from loading at all. Almost nothing outside telecom signalling stacks, some SS7 and Diameter gateways, and a handful of clustering products actually speaks SCTP. Dropping install sctp /bin/true into a file under /etc/modprobe.d/ and confirming the module is not already resident removes the attack surface entirely on the overwhelming majority of servers. Check first: lsmod | grep sctp. If it is loaded and nothing needs it, that is its own finding.

RelatedJanuscape: a 16-Year KVM Bug Escapes Guest to Host

Container operators should treat this as a host-patching problem rather than an image problem. The vulnerable code is the host kernel, which every container shares. A fully patched image on an unpatched node buys you nothing.

How it was found matters as much as what was found

Tencent credits the discovery to Corvus AI, a multi-agent pipeline it built for kernel research. Not a fuzzer flagging a crash for a human to triage, but a system that found the mismatch, built the nine-stage exploit chain, and validated container escape.

Take the claim at face value and the implication is uncomfortable. This bug was reachable by anyone for eighteen years, through syzkaller campaigns, through paid audits, through a decade of SCTP hardening. What changed is not the code, it is the cost of looking at it carefully. Old code in unfashionable subsystems has been protected mostly by the fact that nobody wanted to spend a researcher-month on it. That protection is now weaker for defenders and attackers alike, and the attackers are not obliged to publish.

1. Dec 2007Flawed ASCONF handling ships in Linux 2.6.25 commit 42e30bf3463c
2. Jul 12, 2026Corvus AI identifies the mismatch, private disclosure opens
3. Jul 15, 2026Global root exploitation chain completed
4. Jul 24, 2026Fix merged into the Linux networking tree
5. Jul 27, 2026Container-to-host escape validated
6. Aug 4, 2026CVE-2026-64564 assigned and announced
7. Aug 6, 2026Technical write-up and oss-security thread go public

Our take

The severity rating undersells this one. An 8.5 that requires local access reads as a second-tier problem next to a remote 9.8, and plenty of teams will schedule it accordingly. That reading is wrong for anyone running shared compute. Container escape collapses the distance between "an attacker got code execution in one workload" and "an attacker owns the node," and a 75% success rate across eight attempts is reliable enough to be used, not just demonstrated.

The mitigating factor is real, though: SCTP is genuinely rare in production. Most fleets can neutralize this in an afternoon with a modprobe blacklist and never reboot anything. The organizations that cannot are exactly the ones that should be moving fastest, because they run SCTP for a reason, usually telecom signalling, and usually somewhere that matters.

Original analysis by GenZTech. Technical detail from the Tencent Zhuque Lab write-up and the oss-security disclosure.