SCTPhantom: An 18-Year-Old Linux Kernel UAF That Escapes Containers to Root

Overview

What Is SCTPhantom?

SCTPhantom is a use-after-free in the Linux kernel’s SCTP (Stream Control Transmission Protocol) Dynamic Address Reconfiguration implementation. An attacker who can reach the SCTP stack can trigger a stale-pointer dereference that leads to full root on the host — and, critically, escape a container to compromise the underlying host.

The bug is notable for two reasons:

1. It’s 18 years old. The vulnerable code path was completed in Linux 2.6.25 (2007). It has sat in the kernel for nearly two decades.
2. It was found with AI assistance. Tencent Zhuque Lab’s Corvus AI — a persistent, multi-agent vulnerability research pipeline — developed the initial finding into a reproducible exploit, then a complete privilege-escalation and container-escape chain.

Background: SCTP and ASCONF

SCTP (RFC 4960) is a message-oriented transport protocol with multihoming — a single association can have several peer paths. The Linux kernel represents an association with struct sctp_association and each path with struct sctp_transport, linked through asoc->peer.transport_addr_list.

Two cached pointers matter here:

struct sctp_association
peer.transport_addr_list -> [ transport A ] -> [ transport L ] -> [ transport C ]
peer.primary_path -------------------------------^
peer.active_path  -------------------------------^

primary_path and active_path are expected to point to live transports owned by the association.

RFC 5061 adds SCTP Dynamic Address Reconfiguration. An ASCONF chunk contains an Address Parameter followed by operations such as ADD-IP, DEL-IP, and SET-PRIMARY. Linux processes these operations in message order.

Root Cause

The vulnerable ASCONF chunk uses two different identities:

• S — the IPv4 packet source address
• L — the Address Parameter used to select a transport

The DEL-IP check validates the requested address against S, but later processing relies on the transport selected through L. Because S and L differ, an attacker can craft this ordered sequence:

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

Here’s the failure:

1. DEL-IP L passes the source-address check (because L ≠ S) and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at — freeing it (RCU-deferred).
2. The following wildcard DEL-IP (0.0.0.0) reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers().
3. set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path.
4. del_nonprimary_peers() removes every real transport, leaving the association with transport_count = 0 and primary_path/active_path pointing at freed memory.

A later socket operation dereferences the stale pointer → use-after-free.

The Exploit Chain

Tencent’s completed chain is a full kernel exploitation pipeline:

surviving SCTP transport UAF
→ UAF #1 reclaimed by pg_vec
→ direct-map page disclosure
→ repeatable 4-byte kernel read
→ IDT-based KASLR recovery
→ UAF #2 reclaimed by controlled SCTP authentication-key data
→ controlled kernel object graph
→ data-oriented commit_creds()
→ global root
→ usermode-helper variant
→ container-to-host escape

Surviving UAF

The exploit first needs three conditions to hold simultaneously:

the transport has completed RCU release
AND the association remains alive
AND userspace can still reach the stale path

The stable setup:

create a multihomed association
→ demand heartbeats until the target secondary becomes ACTIVE
→ disable heartbeats on the target and remaining paths
→ inject [Address target][DEL target][wildcard DEL]
→ allow ASCONF processing to return
→ wait for the RCU release
→ access the stale path through the surviving socket

A later getsockopt(SCTP_STATUS) reaches the freed primary path through the live socket. KASAN confirms a slab UAF with allocation/free stacks in sctp_transport_new() and the RCU callback.

pg_vec Leak → Arbitrary Read → KASLR

On the representative 6.6 target, struct sctp_transport occupies a kmalloc-1024 allocation. A TPACKET V1 transmit ring with 128 blocks allocates a 1024-byte pg_vec array that reclaims the freed transport slot. SCTP_STATUS then interprets selected page pointers as transport fields, reconstructing a 64-bit kernel page address — a direct-map disclosure.

This gives the attacker a repeatable 4-byte kernel read primitive, which is used to recover the KASLR slide from the fixed, read-only IDT mapping (UMIP blocks a userspace sidt).

commit_creds → Root → Container Escape

A second vulnerable association installs a fully controlled transport-sized object. The exploit builds a fake object graph (fake transport → fake association → fake socket/cred → fake SCTP address-family ops) inside the disclosed direct-map page, then drives a data-oriented commit_creds() call to gain global root. A usermode-helper variant extends this to container-to-host escape.

The Fix

The upstream fix closes the identity mismatch by rejecting deletion when the selected peer is the transport retained for the ASCONF chunk:

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

The fix changes net/sctp/sm_make_chunk.c. Mainline commit: 9b2854f86f0b.

Fixed Versions

Note: Vendor kernels may backport the change while retaining an older base version. A version string alone does not establish exposure — check the vendor advisory or source package.

Detection & Mitigation

Patch First

The primary mitigation is a kernel update to a fixed version. This is a critical (9.8) kernel bug with a demonstrated container-escape chain — prioritize it.

Defense-in-Depth

• Restrict SCTP exposure. If SCTP isn’t required, block it at the network layer and consider disabling the module. SCTP is used by some telephony/SIGTRAN, DCCP-adjacent, and specific app protocols — assess before disabling.
• Container hardening. The container-escape path relies on reaching the SCTP stack and kernel exploitation primitives. Apply standard hardening: drop capabilities, use seccomp profiles, restrict user namespaces where possible, and keep the host kernel patched (the escape targets the host kernel, so host patching is the real fix).
• Monitor for SCTP socket activity by unprivileged users/processes — anomalous ASCONF traffic or SCTP_STATUS getsockopt calls from non-network services are a red flag.

Broader Context: AI-Assisted Kernel Bug Hunting

SCTPhantom is the latest in a wave of decade-old kernel bugs being rediscovered with AI assistance. The same pattern — an AI research pipeline turning a protocol state-machine anomaly into a full exploit chain — recently surfaced other ancient Linux kernel vulnerabilities (e.g., the 15-year-old bug covered earlier this year).

This has two implications:

1. Old code is not safe code. The kernel is so massive that even 18-year-old, heavily-reviewed paths can hide exploitable bugs. The “it’s been there for years, so it must be fine” assumption is increasingly dangerous.
2. The attack surface is shrinking, but slowly. The kernel community is actively removing legacy cruft (e.g., Appletalk) in response to the AI bug-report influx, and pushing toward memory-safe languages like Rust for new code. But the existing C codebase remains a large target.

For defenders, the practical takeaway is unchanged: patch the kernel, reduce attack surface, and don’t assume age equals safety.

Disclosure Timeline

References

• Tencent Zhuque Lab — SCTPhantom write-up
• NVD — CVE-2026-64564
• CVE record
• Linux kernel CVE announcement
• Mainline fix: 9b2854f86f0b
• Introducing commit: 42e30bf3463c
• RFC 4960: SCTP
• RFC 5061: SCTP Dynamic Address Reconfiguration
• Privacy Guides coverage