HIGH: Linux Kernel SCTP Flaw CVE-2026-64564 Enables Local Root and Container Escape

Every so often a bug turns up that has been sitting quietly in the Linux kernel since before the first iPhone shipped, and this is one of those weeks. Researchers at Tencent's Zhuque Lab have disclosed a use after free vulnerability in the kernel's Stream Control Transmission Protocol code that traces back to a commit landed in Linux 2.6.25 in December 2007. They have named it SCTPhantom, it is tracked as CVE-2026-64564, and it lets an unprivileged local user climb all the way to root on the host and, in the researchers' testing, break out of a container to compromise the machine underneath it. The flaw carries a CVSS v4.0 base score of 8.5, and stable kernels released on August 3, 2026 close it.

The short version is that SCTP got confused about identity. The vulnerability lives in the protocol's Dynamic Address Reconfiguration feature, the part of SCTP that lets an association add or remove IP addresses on the fly without tearing down the connection. When a peer sends a DEL-IP request to drop an address, the kernel validates that request using the source address of the IPv4 packet that carried it. The problem is that the code which actually acts on the request keys off a different value, the address parameter embedded inside the ASCONF chunk. Those two things are supposed to point at the same transport, and for eighteen years nobody made the kernel check that they do.

That gap is enough to build a very deliberate trap. By crafting an ordered ASCONF sequence that supplies one address, then a delete for that address, then a wildcard delete against 0.0.0.0, an attacker can convince the kernel to free a transport structure while leaving stale pointers to it cached in the association's primary_path and active_path fields. The freed object is a struct sctp_transport living in the kmalloc-1024 slab, and once those dangling pointers survive the free, the classic use after free playbook opens up. The vulnerable logic sits in net/sctp/sm_make_chunk.c, and the upstream fix is refreshingly small. The patch simply refuses the deletion when the selected peer transport is the same one the ASCONF chunk arrived on, returning an error rather than freeing an object the kernel is still holding references to.

What Tencent did with that dangling pointer is worth understanding, because it explains why an 8.5 that requires local access should still make you nervous. After deleting a confirmed active secondary transport to keep the association alive, the researchers reclaimed the freed kmalloc-1024 slot using a TPACKET version one pg_vec allocation, which leaked a kernel direct map page address and gave them a foothold against memory layout. From there they abused SCTP_STATUS with a controlled transport pointer to get an arbitrary four byte read, walked the CPU entry area to read an interrupt descriptor table gate and defeat KASLR, then reclaimed the transport one more time with attacker controlled authentication key data to forge an object graph that called commit_creds during packet output. That last step hands the process root credentials. To escape a container, they chained into call_usermodehelper_exec to run commands in the host's initial namespaces. In their words the escape worked without CAP_NET_ADMIN or CAP_SYS_ADMIN and with default seccomp profiles in place, which is exactly the kind of sentence that ruins a security team's afternoon.

The credit here goes to something that is itself part of the story. Tencent attributes the discovery to Corvus AI, a multi agent vulnerability research pipeline built jointly by the TencentOS Security Team and Zhuque Lab. In other words, a machine driven fuzzing and analysis system found an eighteen year old kernel bug that a generation of human eyes walked past. That is a preview of where this field is heading, and if you have been telling yourself that ancient, obscure protocol code is safe simply because it is old and nobody looks at it, this is your notice that the economics of looking just changed.

Now for the part that should temper the panic a little. This is a local vulnerability, not a remote one, and it depends on SCTP being reachable on the target. SCTP is not a protocol most workloads touch. It shows up in telecom signaling, some clustering and storage stacks, and a handful of specialized applications, but the average web server or database host is not speaking it. The catch is that on many Linux distributions the sctp kernel module is not loaded by default but can be autoloaded on demand when an unprivileged process simply requests an SCTP socket. That means the attack surface is often one socket call away even on systems where nobody intended to run SCTP at all. Early versions of the exploit also needed the addip_enable and addip_noauth_enable sysctls turned on, but the researchers developed a later variant that configures what it needs per socket and sidesteps those knobs, so do not treat the default sysctl values as a shield.

As for who is affected, the honest answer is nearly every current Linux system that has not patched, because the bug predates almost every kernel still in service. Tencent reported successful root escalation on Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9, and OpenCloudOS, with six of eight attempted container escapes succeeding across their test matrix. There is no confirmed in the wild exploitation as of this writing, no public exploit code has surfaced, and CISA has not added it to the Known Exploited Vulnerabilities catalog yet. That is the calm before anything, not evidence of safety. A working writeup and a proof of concept from a top tier lab tend to get reproduced quickly, and local privilege escalation bugs are prized building blocks for post exploitation and for breaking multi tenant boundaries.

The fix is straightforward if unglamorous. Upstream stable kernels 7.1.6, 6.18.42, 6.12.101, and 6.6.148 shipped on August 3, 2026, and the mainline fix rides in 7.2-rc5. Because distributions routinely backport security fixes without bumping the marketing version number, the right move is to check your vendor's security tracker rather than eyeballing uname output and assuming an older looking version is unpatched. Apply the kernel update and reboot, which for a kernel level use after free is the only real remediation. There is one more wrinkle worth flagging, which is that a second, related dangling transport use after free in the same code was patched on August 6, after the August 3 stable releases went out, so make sure whatever you install actually includes both fixes and is not just the first round.

If you genuinely cannot patch immediately, you can shrink the attack surface by preventing the sctp module from loading. Blacklisting the module and disabling on demand autoloading for it removes the vulnerable code from reach entirely on hosts that have no business speaking SCTP, which is most of them. On systems that do rely on SCTP you do not have that luxury and patching is the only answer. For detection, defenders can watch for unexpected loads of the sctp module, for unprivileged processes opening SCTP sockets on hosts that never should, and for ASCONF traffic in environments where dynamic address reconfiguration is not a normal thing to see. None of that replaces the patch, but it buys visibility while you roll updates across a fleet.

For managed service providers, a kernel bug this widespread is a clean reason to have the patch cadence conversation with clients who still treat operating system updates as a quarterly chore. SCTPhantom is a tidy anchor for a proactive patch management and vulnerability remediation offering, especially for customers running container platforms and multi tenant workloads where a local escalation quietly becomes a host takeover. It also opens the door to a broader kernel hardening and attack surface reduction service, the sort of engagement where you audit which modules a client actually needs, blacklist the rest, and turn a scary headline into a retainer. The clients most exposed here are precisely the ones running dense virtualization and container estates, and those are the accounts where a demonstrated container escape makes the value of your service obvious without much of a sales pitch.