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.