18-Year-Old Linux SCTP Flaw Could Let Local Users Gain Root and Escape Containers

Aug 07, 2026 - 16:07
0 0
18-Year-Old Linux SCTP Flaw Could Let Local Users Gain Root and Escape Containers

Swati KhandelwalAug 07, 2026Linux / Vulnerability

A use-after-free bug in Linux's SCTP networking code can be turned into full root on a host, and Tencent researchers say they used it to escape a container and reach the machine underneath.

The flaw has existed since 2008. The fix already shipped: stable kernels 7.1.6, 6.18.42, 6.12.101 and 6.6.148, released August 3, close it. Anyone running an older kernel with SCTP reachable should update.

Tracked as CVE-2026-64564 and named SCTPhantom by its finders, the flaw was disclosed publicly on August 6, two days after the kernel CVE team assigned it. No public exploit code had surfaced at the time of writing, and The Hacker News found no entry for the flaw in CISA's Known Exploited Vulnerabilities catalog as of August 7.

The flaw is local, not remote, and it needs SCTP reachable on the target, which limits exposure. Where those conditions held, Tencent Zhuque Lab reports it got root on the kernel builds it tested for Debian 13, Ubuntu 24.04, Rocky Linux 9 and RHEL 9, and OpenCloudOS.

Cybersecurity

SCTP is a transport protocol that lets one connection run over several network paths at once. A companion feature, dynamic address reconfiguration, lets a peer add or drop those addresses mid-connection.

The bug is a mix-up over identity: the kernel checks a delete request against the packet's source address, but acts on a path it picked using a different address inside the message. Per the kernel's own advisory, one message can carry an address, a delete for that same address, then a wildcard delete. That sequence frees the path, then reuses the dead pointer, leaving the connection pointing at memory the kernel has already released.

The patch refuses a delete aimed at the path the message is being processed against. The bug traces to Linux 2.6.25 in 2008 and has been in every kernel released since.

Tencent's container escape claim is based on its own testing. In its write-up, the lab says an early version of its 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. It later found a route that leaves both untouched by enabling the features per socket instead.

The lab says its escape test kept the default seccomp profile and granted neither CAP_NET_ADMIN nor CAP_SYS_ADMIN. By its count, six of eight attempts reached root on the host.

No one outside the lab has reproduced any of that, and the write-up does not name the container runtime it tested against. The lab itself notes that socket access, seccomp profiles, and user-namespace policy all shift exposure elsewhere. An openKylin advisory covering the same bug goes no further than kernel panic and denial of service.

Cybersecurity

The severity number is unsettled too. Tencent scored it 8.5 under CVSS v4.0. NVD had assigned neither a score nor a weakness classification as of August 7.

Vendors often backport fixes without moving to a new upstream version, so a kernel version string alone will not tell you whether you are covered; check your distribution's tracker. A second dangling-transport use-after-free in the same code was patched on August 6, after the August 3 stable releases shipped, so those kernels do not carry it. Where SCTP is not needed, blocking the module removes the attack surface outright.

Tencent credits the find to Corvus AI, a multi-agent research pipeline it built for kernel work, making SCTPhantom the latest in a run of long-dormant kernel flaws surfaced with machine assistance this year, alongside GhostLock in July. It also lands the same day as Zapscape, an unrelated KVM escape, and the same four stable releases carry both fixes.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

What's Your Reaction?

Like Like 0
Dislike Dislike 0
Love Love 0
Funny Funny 0
Wow Wow 0
Sad Sad 0
Angry Angry 0

Comments (0)

User