Tencent’s Zhuque Lab has disclosed CVE-2026-64564, nicknamed “SCTPhantom” — a use-after-free in the Linux kernel’s SCTP (Stream Control Transmission Protocol) Dynamic Address Reconfiguration (ASCONF) code that lets a local attacker escalate to root and, in certain configurations, escape containers onto the host. The vulnerable logic has shipped since Linux 2.6.25, released in 2008, making this an 18-year-old regression sitting in a kernel module that ships enabled on most mainstream distributions. Fixes have landed upstream and in stable branches; the Linux kernel CVE team formally announced the assignment on August 4, 2026, after a private disclosure window that began July 12.

What’s broken

SCTP’s ASCONF extension lets an endpoint add, delete, or set a primary IP address on an already-established association without tearing it down — used for multihoming failover. The bug is an identity mismatch inside that path: when the kernel processes a crafted, ordered sequence of ASCONF DEL-IP operations, it validates the delete against the packet’s source address, while a separate cached pointer used to select the actual network path (the “transport” object) is keyed on the address parameter carried inside the ASCONF chunk. An attacker can exploit that mismatch to get a transport object freed while a stale reference to it remains live elsewhere in the association’s state.

Tencent’s researchers turned the resulting use-after-free into a working local-privilege-escalation chain: controlled heap reallocation forces attacker-controlled data into the freed transport slot, which yields a kernel memory disclosure primitive, followed by corruption of kernel object relationships sufficient to escalate to root. They report full root on kernel builds they tested for Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9, and OpenCloudOS. Because the corrupted state lives in the host kernel rather than anything namespace-scoped, the same primitive escapes container boundaries on configurations where an unprivileged container can reach the SCTP stack.

The flaw is fixed upstream via kernel commit 9b2854f86f0b and has been backported to stable branches 6.6.148, 6.12.101, 6.18.42, and 7.1.6.

Exposure

  • Local, not remote. Exploitation requires local code execution and the SCTP protocol module reachable and loaded on the target — this is not a network-facing zero-click bug.
  • CVSS v4.0 8.5 (High).
  • net-sctp is not obscure. The module auto-loads on demand via AF_INET/SOCK_SEQPACKET socket creation on most distributions rather than requiring an admin to enable it, which is why the exposure is broader than “who runs SCTP on purpose.” Telecom signaling (Diameter, M3UA/SIGTRAN), some Kubernetes CNI and service-mesh implementations, and certain VoIP and 5G core workloads use SCTP directly; any host or container that lets an unprivileged local user trigger module autoload is potentially exposed even without an admin explicitly configuring SCTP.
  • Multi-tenant and CI infrastructure — shared Linux hosts, CI/CD build runners, and container platforms where untrusted code runs as a local, non-root user — carry the most risk, consistent with the pattern of 2026’s other kernel LPE-with-container-escape disclosures (Copy Fail, Dirty Frag, GhostLock).

What to do now

  1. Patch the kernel. Pull the build for your distribution carrying commit 9b2854f86f0b or the corresponding backport (6.6.148, 6.12.101, 6.18.42, 7.1.6, or later) and reboot. Debian 13 has already shipped a kernel security update covering SCTPhantom alongside the separate “Zapscape” fix; check Ubuntu, RHEL/CloudLinux, and SUSE advisories directly for your branch’s backport status.
  2. If you don’t need SCTP, blacklist it. Unlike some recent kernel LPEs, this one has a real workaround: install sctp /bin/false in a modprobe config (or rmmod sctp plus a blacklist entry) prevents the module from loading and closes the attack surface entirely on hosts with no legitimate SCTP use.
  3. Container and Kubernetes fleets: don’t rely on image hygiene — this is a host-kernel bug, not an application-layer one. Prioritize node-level kernel patching, and where SCTP isn’t required, block or disable the module at the node image level as defense in depth alongside patching.
  4. Audit exposure first if you can’t patch immediately. Check whether sctp is loaded (lsmod | grep sctp) across your fleet — hosts where it’s never loaded are lower urgency than hosts running SCTP-dependent workloads (telecom, some service meshes) that can’t simply blacklist the module.
  5. No live-patch coverage confirmed yet — check with your live-patching vendor before treating a host as covered without a reboot.

Why this one matters

SCTPhantom extends a run of 2026 Linux kernel disclosures — Copy Fail, Dirty Frag, GhostLock — where multi-year-old regressions in core kernel networking or scheduling code turn into root-plus-container-escape chains once a well-resourced research team goes looking. The pattern engineers should take from this year: local-root kernel bugs with container-escape reach are no longer rare edge cases, they’re a recurring class, and node-level kernel patch cadence deserves the same urgency as application-layer patching on any host running untrusted or semi-trusted local workloads.

References