# SCTPhantom (CVE-2026-64564): 18-Year-Old Use-After-Free in Linux Kernel SCTP ASCONF Handling Enables Local Privilege Escalation

> Tencent Zhuque Lab's Corvus AI research pipeline disclosed CVE-2026-64564 ("SCTPhantom"), an 18-year-old use-after-free in the Linux kernel's SCTP ASCONF (RFC 5061) dynamic-address-reconfiguration handling that lets a local, unprivileged attacker escalate to root and, in some configurations, escape containers to the host. No public exploit code exists and the flaw is not in CISA's KEV catalog, but fixes are already shipping in stable kernels and major distributions.

- **Published:** 2026-08-09T00:00:00Z
- **Last reviewed:** 2026-08-09T07:46:49.925Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1949
- **ID:** TL-2026-1949
- **Severity:** HIGH (CVSS 8.5)
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 21 (full data via the Threadlinqs MCP server — Purple tier)
- **CVEs:** CVE-2026-64564

## Description

CVE-2026-64564 ("SCTPhantom") is a use-after-free (CWE-416) in the Linux kernel's SCTP Dynamic Address Reconfiguration (ASCONF, RFC 5061) code, in `net/sctp/sm_make_chunk.c`. The root cause is an identity mismatch between two values used during ASCONF DEL-IP processing: the IPv4 packet source address (S), used for the DEL-IP validation check, and the Address Parameter (L) inside the chunk, used to select the actual transport object. A single, ordered ASCONF sequence -- add address L, DEL-IP L, then a wildcard DEL-IP 0.0.0.0 -- frees `transport(L)` while the wildcard delete still caches a stale pointer to that freed transport in the association's `primary_path`/`active_path` fields, so later socket operations dereference freed kernel heap memory. The vulnerable logic traces to kernel commit `42e30bf3463c`, merged in Linux 2.6.25 (per Tencent Zhuque Lab and cybersecuritynews.com, "December 2007"), making it roughly 18 years old at disclosure.

Tencent Zhuque Lab (via its Corvus AI automated vulnerability-research pipeline, combining coding agents with multi-agent coordination) built and privately validated a full local-root exploit chain: (1) trigger the UAF with a crafted multihomed-association ASCONF sequence (`socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP)`), then call `getsockopt(SCTP_STATUS)` to dereference the freed transport once its RCU grace period elapses; (2) reclaim the freed `sctp_transport` object (a kmalloc-1024 slab allocation) using a TPACKET_V1 packet-socket ring buffer (`pg_vec`), establishing a dual userspace/kernel virtual mapping onto the same physical page, then use `SCTP_STATUS` to read page-pointer fields back out as transport fields, disclosing a kernel direct-map address; (3) use the hijacked `transport->asoc` pointer with `sctp_assoc2id()` as an arbitrary 4-byte kernel-memory read primitive; (4) read IDT gate 0 from the fixed per-CPU entry area -- a read that bypasses UMIP (User-Mode Instruction Prevention) -- to reconstruct the runtime address of the `asm_exc_divide_error` handler and derive the kernel text KASLR slide; (5) reclaim the dangling transport a second time with attacker-controlled SCTP authentication-key data to build a fake kernel object graph whose fake address-family operations point at `commit_creds()`, then trigger execution via `setsockopt(SO_LINGER)` followed by `close()`, which drives an SCTP ABORT down the packet-output path into the fake handler -- a data-oriented technique that invokes only existing kernel code paths, avoiding conventional shellcode or ROP chains, and yields root; and (6) on container hosts, enable `SCTP_ASCONF_SUPPORTED` and `SCTP_AUTH_SUPPORTED` per-socket (removing the need for the addip sysctls or CAP_NET_ADMIN/CAP_SYS_ADMIN) and abuse `call_usermodehelper_exec()` with a crafted `subprocess_info` to execute in the host's initial namespaces, achieving container-to-host escape. Tencent reports achieving root in six of eight attempts (75%) while default seccomp profiles, LSM policies, and user-namespace restrictions remained in place -- the two failures were clean pointer-walk misses rather than kernel panics. The Corvus AI pipeline itself automates kernel-tree navigation, PoC iteration, kernel build/boot cycling, sanitizer analysis, and crash triage. Tencent notes "no one outside the lab has reproduced any of that," and that runtime, seccomp, and namespace policy choices materially affect real-world exposure.

Tencent's public write-up documents the exploit engineering in granular detail beyond the six-step summary. The UAF-triggering ASCONF sequence first forces the targeted secondary transport into ACTIVE state by demanding heartbeats, then disables heartbeats on that path and the remaining paths before firing the wildcard DEL-IP; the exploit also blackholes the spoofed source address used in the ASCONF packet so a stray ASCONF-ACK cannot allocate a replacement transport and corrupt the heap-grooming layout. The reclaim step uses a TPACKET_V1 transmit ring built from 128 blocks sized to match the freed 1024-byte `pg_vec` array against the vacated `sctp_transport` slot, and pins receive processing, the RCU callback, and the reclaim allocation to the same per-CPU slab path for determinism; `SCTP_STATUS` then reads the reclaimed ring's page-pointer bytes back out through the transport's `srtt` and `cwnd` fields, disclosing a single 64-bit kernel direct-map address that aliases the same physical page as a userspace mapping. The arbitrary 4-byte read primitive works by setting `transport->asoc` to `target_address - offsetof(struct sctp_association, assoc_id)`, so a subsequent `SCTP_STATUS` call returns the value at the target address via the `assoc_id` field; every read is validated against canonical-address and known-value checks, and the exploit requires a reclaim to return a marker such as `0x1337beef` before proceeding, rejecting any attempt that fails those checks. The final trigger -- `setsockopt(SO_LINGER, {on=1, linger=0})` followed by `close()` -- forces an abortive SCTP ABORT down `sctp_transport_route()` into the fake `af_specific->get_saddr` function pointer, invoking `commit_creds()` on a fully attacker-controlled `cred` structure. Tencent verified root by diffing access to `/etc/shadow` before and after the trigger and by creating a root-owned file under `/root`. The container-escape variant is confirmed to work with the default seccomp profile active and neither `CAP_NET_ADMIN` nor `CAP_SYS_ADMIN` granted to the container, using `call_usermodehelper_exec()` with the crafted `subprocess_info` structure so the resulting usermode-helper process runs in the host's initial namespaces.

Tencent validated root-level exploitation against Linux 7.2-rc2, OpenCloudOS 6.6.119, Debian 13 (kernel 6.12.95), Rocky Linux 9 / RHEL 9 (kernel 5.14 with the sctp module loaded), and Ubuntu 24.04 (kernel 6.8.0-134). openKylin's own advisory, by contrast, scoped the issue to kernel-panic/denial-of-service impact only, illustrating that assessed impact varies by vendor and build. Tencent self-rates the flaw CVSS v4.0 8.5 (High) -- `CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N`; as of August 7, 2026 NVD had not yet published its own CVSS score or CWE classification for the CVE.

CVE-2026-64564 was assigned August 4, 2026 and publicly disclosed August 6, 2026 alongside Tencent's technical write-up. The upstream fix (commit 9b2854f86f0b, rejecting any DEL-IP request that targets the transport still referenced by the current ASCONF chunk) landed in Linux 7.2-rc5 and was backported to stable branches 6.6.148, 6.12.101, 6.18.42, and 7.1.6, which shipped August 3, 2026 -- one day before the CVE was even assigned. Notably, a second, related dangling-transport use-after-free in the same ASCONF code path was found and patched on August 6, 2026, after those stable releases had already shipped, so hosts running only the August 3 stable builds are still missing this second fix. Debian shipped DSA-6415-1 on August 6, 2026 (linux 6.12.101-1 for Debian 13/trixie), bundling CVE-2026-64564 with 27 other kernel CVEs. As of publication (August 7-8, 2026), no public proof-of-concept exploit code had surfaced, and the CVE is not listed in CISA's Known Exploited Vulnerabilities catalog.

## MITRE ATT&CK

- T1611 Escape to Host
- T1611 Escape to Host
- T1499.004 Application or System Exploitation
- T1587.004 Exploits
- T1588.006 Vulnerabilities
- T1106 Native API
- T1082 System Information Discovery
- T1078.003 Local Accounts
- T1003.008 /etc/passwd and /etc/shadow
- T1595.002 Active Scanning
- T1068 Exploitation for Privilege Escalation
- T1211 Exploitation for Defense Evasion
- T1518 Software Discovery

## Sources

- [18-Year-Old Linux Kernel SCTP Vulnerability Let Attackers Escalate Privileges](https://gbhackers.com/18-year-old-linux-kernel-sctp-vulnerability/)
- [SCTPhantom: An 18-Year-Old SCTP ASCONF Transport Use-After-Free](https://matrix.tencent.com/en/2026/08/06/sctphantom-CVE-2026-64564)
- [18-Year-Old Linux SCTP Flaw Could Let Local Users Gain Root and Escape Containers](https://thehackernews.com/2026/08/18-year-old-linux-sctp-flaw-could-let.html)
- [18-Year-Old Linux Kernel SCTP Vulnerability Lets Attackers Gain Full Root on Host](https://cybersecuritynews.com/18-year-old-linux-kernel-sctp-vulnerability/)
- [SECURITY DSA 6415-1 linux security update](https://lists.debian.org/debian-security-announce/2026/msg00326.html)
- [CISA Known Exploited Vulnerabilities Catalog (CVE-2026-64564 not present as of 2026-08-07)](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json)
- [NVD - CVE-2026-64564](https://nvd.nist.gov/vuln/detail/CVE-2026-64564)
- [New Debian 13 Kernel Security Update Fixes "Zapscape" and "SCTPhantom"](https://9to5linux.com/new-debian-13-kernel-security-update-fixes-zapscape-and-sctphantom)
- [SCTPhantom Linux Kernel Flaw Lets Local Attackers Gain Root and Escape Containers](https://cyberpress.org/sctphantom-linux-kernel-flaw/)
- [oss-security: Re: CVE-2026-64564: Linux SCTP ASCONF transport UAF leading to local privilege escalation and container escape](https://www.openwall.com/lists/oss-security/2026/08/06/13)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1949