SCTPhantom: 18-Year-Old Linux SCTP Vulnerability Grants Root

A use-after-free in the Linux kernel's SCTP networking code, present since 2008, lets a local attacker gain root and, in Tencent's evaluations, escape a container to the host. Tracked as CVE-2026-64564 and named SCTPhantom, the flaw has a fix in stable kernels released August 3, 2026. Here is what the bug is, why this linux sctp vulnerability took 18 years to surface, and how to check whether your fleet is covered.

Vulnerability Details

CVE-2026-64564 is a use-after-free in SCTP ASCONF processing. SCTP is a transport protocol that runs one connection over several network paths at once; dynamic address reconfiguration, or ADDIP, lets a peer add or remove addresses mid-connection. The free-after-use happens when the kernel handles a delete request for an address that differs from the packet's source.

The kernel assigned the CVE on August 4, 2026, and the flaw was disclosed publicly on August 6. The official Linux CNA record scores it 9.8 Critical under CVSS 3.1; Tencent Zhuque Lab, which found it, rates it 8.5 under CVSS v4.0. No public exploit code had surfaced at the time of writing, and the flaw was not in CISA's Known Exploited Vulnerabilities catalog as of August 7.

The bug is local, not remote, and it needs SCTP reachable on the target, which narrows exposure considerably. Where those conditions hold, Tencent reports root on kernel builds for Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 and OpenCloudOS. An openKylin advisory for the same bug goes only as far as kernel panic and denial of service.

Root Cause: The ASCONF Identity Mix-Up

The kernel caches the transport an ASCONF chunk is processed against in asconf->transport. For an ASCONF located through its Address Parameter, that cached transport corresponds to the parameter, which need not be the packet's source address. The D8 rule rejects a DEL-IP for the source address, but nothing protects asconf->transport itself.

Per the kernel advisory, a single ASCONF message can carry, in order:

[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]

where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport the cache still points at, freeing it with an RCU deferral. The wildcard DEL-IP that follows then reuses the dangling pointer in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(). set_primary() dereferences the freed transport and plants the dangling pointer into the association's primary and active path fields. del_nonprimary_peers() keeps only the pointer that is no longer on the list, removing every real transport and leaving the association with a transport count of zero and path fields pointing at freed memory.

The fix rejects a DEL-IP that targets the transport the message is being processed against. The bug traces to Linux 2.6.25 in 2008, which means every kernel released in the last 18 years carries it.

Container Escape Evaluations

Tencent Zhuque Lab says the flaw was found by Corvus AI, a multi-agent research pipeline the lab built for kernel work. SCTPhantom joins a run of long-dormant kernel flaws surfaced with machine assistance this year, alongside GhostLock in July; it also landed the same day as Zapscape, an unrelated KVM escape, and the same four stable releases carry both fixes.

In the lab's write-up, an early version of the exploit needed the net.sctp.addip_enable and net.sctp.addip_noauth_enable sysctls switched on, which made CAP_NET_ADMIN look like a prerequisite. A later route enables the features per socket instead, leaving both sysctls untouched. The escape evaluation kept the default seccomp profile and granted neither CAP_NET_ADMIN nor CAP_SYS_ADMIN. By the lab's count, six of eight attempts reached root on the host.

Reality checks apply. No one outside the lab has reproduced the result, and the write-up does not name the container runtime used. The lab itself notes that socket access, seccomp profiles and user-namespace policy all shift exposure elsewhere.

Impact Assessment

The practical risk sits in shared infrastructure: containers, CI runners and multi-tenant hosts where SCTP is enabled. Because the primitive is local, the attacker already has code execution inside a namespace or account. What SCTPhantom adds is the escape: the jump from unprivileged code to host root. On kernel builds where the chain works, that defeats container isolation entirely.

Systems that never load the SCTP module are not exposed. Systems with SCTP reachable, especially distributions that enable it by default or setups that expose it to guest VMs, should move to a fixed kernel promptly.

Mitigation and Patching

The fix shipped in stable kernels 7.1.6, 6.18.42, 6.12.101 and 6.6.148, released August 3, 2026. A second dangling-transport use-after-free in the same code was patched on August 6, after those stable releases shipped, so the August 3 kernels do not carry it. Confirm coverage through the distribution tracker rather than the kernel version string alone, because vendors often backport fixes without moving to a new upstream version.

Check your running kernel with:

uname -r

Then verify that version against your distribution's security tracker (Ubuntu CVE tracker, Red Hat CVE database, Debian security tracker). Where SCTP is not needed, block the module to remove the attack surface outright:

echo "install sctp /bin/true" | sudo tee /etc/modprobe.d/sctp-block.conf sudo modprobe -r sctp

Note: modprobe -r sctp only succeeds when the module is not in use; a reboot with the modprobe.d rule in place is the clean way to keep it unloaded.

Frequently Asked Questions

Q: Is CVE-2026-64564 remotely exploitable? The official record classifies the vector as network because a remote peer on an established association can trigger it by sending a crafted ASCONF. In practice the disclosed chain needs an existing association and local access; treat it as local unless your SCTP endpoints accept associations from untrusted peers.

Q: Which kernels fix SCTPhantom? Stable releases 7.1.6, 6.18.42, 6.12.101 and 6.6.148 from August 3, 2026. Follow your distribution tracker for backports.

Q: How was an 18-year-old bug found? Tencent Zhuque Lab attributes the find to Corvus AI, its multi-agent kernel research pipeline. Machine-assisted auditing is surfacing a stream of long-dormant kernel flaws this year.

Q: Do I need CAP_NET_ADMIN to exploit this? Tencent's final route enables the ADDIP features per socket, leaving the sysctls untouched and requiring neither CAP_NET_ADMIN nor CAP_SYS_ADMIN.

Q: Is there a public exploit? No public exploit code had been released at the time of writing.

Key Takeaways

• CVE-2026-64564 is an 18-year-old use-after-free in SCTP ASCONF processing, fixed in stable kernels released on August 3.
• Tencent demonstrated host root from a container with the default seccomp profile in six of eight attempts, but no independent reproduction exists yet.
• The attack is local and needs SCTP reachable; if you never load the sctp module, you are not exposed.
• Verify coverage via your distribution tracker, not the kernel version string alone; a follow-up fix in the same code shipped after the stable releases.
• Machine-assisted kernel research is now routinely surfacing decade-old flaws, so expect more of these patch cycles.

---

Sources: Tencent Zhuque Lab write-up | The Hacker News coverage | CVE record for CVE-2026-64564 | openKylin advisory