Linux Kernel SCTP Flaw Let Local Users Gain Root for 18 Years

An AI found a hole in the Linux kernel that sat open for 18 years, then wrote the exploit that turns a local user into root. The machines were not misconfigured. The bug was in the kernel itself, since 2007. 🧐

Researchers at Tencent’s Zhuque Lab published the full analysis on 6 August. They track it as CVE-2026-64564 and named it SCTPhantom. It lets a normal user on a Linux machine climb all the way to root, and from inside a container it can break out onto the host underneath. The code that made this possible went in during December 2007. It reached users with kernel 2.6.25 in April 2008, and has been in the kernel ever since. The fix landed at the start of August. That is eighteen years of a flaw sitting in a file few people ever open. It could not have been used this way in 2008, though. The path to root Tencent built relies on kernel machinery that did not exist yet.

It lives in SCTP, a corner of the kernel few systems ever use.

The connections your browser and apps make run on TCP, the protocol that opens a reliable link and makes sure the pieces arrive in order. SCTP does a similar job, but it was built for a different setting. It carries phone-network signaling, some database clusters, and setups where one connection needs several network paths at once so it survives a link going down. Hardly any Linux machines load it by default. The code sits there, ready, and that turned out to be enough.

SCTP has a feature that lets a live connection add or drop those network paths without hanging up. If your phone moves from WiFi to mobile data, the connection can swap the address it uses and keep going. That feature is called ASCONF, and the bug lives inside it. An attacker sends a short, ordered set of instructions in one ASCONF message and gets the kernel to free a piece of memory that is still in use.

It comes down to two addresses the kernel treats as one. When it checks whether a delete is allowed, it looks at the address the packet came from. When it carries out the work, it uses a different address named inside the message. Those two do not have to match.

So an attacker sends one ASCONF message with the operations in this order:

1

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

The first delete passes the check and removes the path called L. The wildcard delete right after it reuses the saved pointer to that same path, the one that was just freed. The kernel writes that dead pointer into the connection’s primary and active path, then removes the paths that are still there. What remains is a connection with zero live paths and two pointers into memory the kernel already handed back. That is a use-after-free: the memory is gone, but the kernel keeps reading and writing it as if it were live. From there the attacker owns a spot in kernel memory that the system still trusts.

This is not a race that sometimes wins and sometimes misses. It works the same way each time. Line up the sequence and the path gets freed, run after run.

The fix upstream is one check. Refuse the delete when the target is the exact path the message itself is still holding:

1
2
3
4
5
6
7
8

         peer = sctp_assoc_lookup_paddr(asoc, &addr);
         if (!peer)
                 return SCTP_ERROR_DNS_FAILED;

+        if (peer == asconf->transport)
+                return SCTP_ERROR_REQ_REFUSED;
+
         sctp_assoc_rm_peer(asoc, peer);

Two added lines, and the eighteen-year-old hole closes.

What happens next turns a crash into full control. Here is the chain the researchers built, step by step:

• the freed SCTP path (first use-after-free)
• → refill the freed slot with a packet ring buffer
• → leak a kernel memory address
• → turn it into a repeatable 4-byte read
• → recover the KASLR layout from a fixed CPU table
• → a second use-after-free, refilled with data the attacker controls
• → build a fake object graph and call commit_creds
• → root on the machine
• → or, from a container, a kernel helper that runs on the host

The freed slot gets refilled with a packet ring buffer, a normal Linux feature for sending raw packets, which hands back a kernel address and turns into a four-byte read anywhere in memory. That read defeats KASLR, the defense that hides where the kernel loads, by pulling the layout straight from a fixed table the CPU keeps. A second use-after-free, refilled the same way, then lets the exploit reach commit_creds, the one function that rewrites a process’s identity and hands it the rights of root.

None of this runs code the attacker supplied. It calls kernel functions that were already there, so defenses watching for injected code see nothing. The researchers proved full root by reading /etc/shadow, which only root can open, and writing a file under /root.

It worked on the machines people run. Root on Debian 13, Ubuntu 24.04, OpenCloudOS, and on Rocky Linux 9 and RHEL 9 with the SCTP module loaded. The container escape is the part that should get attention. Six out of eight tries reached root on the host, by the lab’s own count, from inside a container running with its default sandbox, with no CAP_NET_ADMIN and no CAP_SYS_ADMIN, the extra powers a container is sometimes handed.

Earlier versions of the proof switched on two SCTP settings that only an admin can change, which made it look like you needed admin rights inside the container for the escape to matter. The AI later found a route that turns the feature on for its own socket, so it needs none of that. A plain container, default settings, and it walks out onto the host.

The escape is a separate final step, not a bonus on top of root. The exploit points a kernel helper at code it controls, and that helper runs in the host’s own space, outside the container. Of the eight tries, the two that failed did not crash the machine. They stopped as quiet misses, without the kernel panic that would put something in front of an admin. For a defender that is the hard part: when it works you are root, and when it does not there is nothing obvious to find.

Even the severity number is not settled. Tencent scored it 8.5 out of 10, and that score leaves the container escape out of the math entirely. On 8 August the Linux kernel team put its own number on it, 9.8, marked reachable over the network with no privileges. NVD has not scored it at all. Take your pick.

In practice this is not a remote attack. The attacker is already on the machine, as an ordinary user or inside a container, and SCTP has to be reachable. That last part matters, because hardly anything loads SCTP. It carries the signaling behind 4G and 5G networks, runs under some database clusters and servers with more than one network link, and rides along with Kubernetes on some container platforms.

On many Linux machines the module stays unloaded until a program opens an SCTP socket, and an ordinary user can trigger that load unless the module is blocked. Rocky Linux and RHEL sidestep it: SCTP is not in a normal install, it lives in an add-on package with the module already blocked, so someone has to add it and load it on purpose. So the question for your box is simple. Can SCTP load, and does anything use it.

What to do is short.

Patch to a fixed kernel: 6.6.148, 6.12.101, 6.18.42, or 7.1.6, or your distribution’s build that carries the fix. Do not trust the version number. Rocky Linux 9 and RHEL 9 report a 5.14 kernel and were still vulnerable, because vendors patch their own build and keep the old number. Read the advisory, not uname.

If you cannot patch yet and you do not use SCTP, block the module so it cannot load:

1
2
3

lsmod | grep sctp
sudo sh -c "printf 'install sctp /bin/false\n' > /etc/modprobe.d/block-sctp.conf"
sudo rmmod sctp

Those lines check whether SCTP is loaded, stop it loading again (even a direct modprobe, which the weaker blacklist does not), and unload it if nothing is using it. For containers the host kernel is what counts, so block it there, not just in the image. Blocking AF_PACKET in containers also removes the trick the exploit uses to grab that freed memory, even before you patch.

One more fix is worth having, and most coverage skips it. A second use-after-free in the same SCTP code was fixed on 6 August, three days after those stable kernels shipped, so they do not carry it. Different route: a HEARTBEAT ACK left in a queue keeps a pointer to a network path that gets removed under it, and the pointer goes stale. The fix is fresh in the kernel tree, so your distribution may not have it yet. If you patch for this bug, check that the second one came too.

That second fix has a history that says a lot about old code. Back in 2018 the same developer fixed the same shape of bug in the same function, after an automated fuzzer found it, but only for one of the two queues it lives in. The other queue kept the flaw for another eight years, until now.

The full method is already public in the writeup. No drop-in exploit has surfaced yet, and that is exactly why the time to patch is now, before one does.

The find, the exploit, and the container escape all came out of Corvus AI, a research setup that reads the kernel source, builds and boots test kernels, reads the crash reports, and shapes the next test from them. It even found the route around the admin settings that a quick summary would have missed. This year keeps turning up bugs that sat untouched for a decade or more, found with AI. Here it did more than spot the flaw. It built the path from a normal login to root on the host.

Want to learn how attackers turn a normal user account into full control of a machine? You start at the basics and build up from there. I cover Linux, networking, privilege escalation, post-exploitation, and taking a raw proof-of-concept and getting it to run, step by step, in my ethical hacking course:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Tencent Zhuque Lab | NVD CVE-2026-64564 | Linux Kernel Patch