TL;DR: SCTPhantom is a Linux kernel use-after-free in SCTP Dynamic Address Reconfiguration. An ordered ASCONF sequence can remove a transport and then reuse its stale pointer, leaving the association with dangling path references. Corvus AI developed the initial finding into a reproducible vulnerability and demonstrated local privilege escalation and container-to-host escape on the tested systems. The issue is tracked as CVE-2026-64564 and fixed upstream by 9b2854f86f0b . 1. Background Hunting for bugs in protocol code such as SCTP often means tracing dense state machines that single-pass analyzers struggle to follow. Coding agents can handle much of the mechanical work: navigating a large kernel tree, iterating on a proof of concept, building and booting a kernel, collecting sanitizer reports or panic logs, and using those results to shape the next experiment. Coding Agent can already cover most execution loops, but a comprehensive study of kernel vulnerabilities still requires research decisions that go beyond the code-generation level, and these decisions and supporting evidence must be consistently preserved across tasks and models. Corvus AI, developed jointly by TencentOS Security Team (Tencent Zhuque Lab) , turns this process into a persistent, multi-agent vulnerability research pipeline. FIGURE 1 — Corvus AI: OS Vulnerability Research Pipeline. SCTPhantom is a concrete example of that workflow. The vulnerability is in Linux SCTP Dynamic Address Reconfiguration. It arises from an inconsistency between the address used to validate a DEL-IP operation and the transport retained for subsequent ASCONF processing. The rest of this article explains how the vulnerability was discovered and validated, how it was developed into a complete privilege-escalation chain, and how it was fixed upstream. 2. Vulnerability 2.1 Discovery The investigation used a structured SCTP research plan to define the search space, including peer-controlled fields, ASCONF parameter ordering, multihoming state, and transport ownership. Corvus AI converted these areas into bounded source-analysis, packet-generation, crash-triage, and VM-reproduction tasks. The issue emerged after separating the IPv4 packet source from the transport selected through the ASCONF Address Parameter. By varying peer transport states, the tests produced a reproducible case in which a later socket operation accessed a released transport. Fresh-boot reproduction confirmed the use-after-free. 2.2 SCTP and ASCONF The Stream Control Transmission Protocol, defined by RFC 4960 , is a message-oriented transport protocol with multihoming support. A single association can contain several peer paths. Linux represents the association with struct sctp_association and each path with struct sctp_transport . The transports are linked through asoc->peer.transport_addr_list . Two cached pointers are important to this bug: 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 operation parameters in message order. 2.3 Root Cause The vulnerable ASCONF chunk uses two different identities: the IPv4 packet source S and the Address Parameter L used to select a transport. The DEL-IP check validates the requested address against S , while later processing relies on the transport selected through L . This allows the following ordered sequence: [ Address Parameter L ] [ DEL-IP L ] [ DEL-IP 0.0.0.0 ] Because S and L are different, DEL-IP L passes the source-address check and removes transport(L) . The wildcard DEL-IP then reuses the cached pointer to that transport as the path to preserve. As a result, the association can retain the removed transport in primary_path and active_path , allowing a later socket operation to dereference a stale pointer. The upstream fix closes this identity mismatch by rejecting deletion when the selected peer is the transport retained for the ASCONF chunk. 3. Exploit Chain The completed chain is: 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 Corvus AI preserved the evidence and constraints from each stage so that the chain could be developed and validated incrementally. 3.1 Surviving UAF The exploit first needs three conditions to hold at the same time: the transport has completed RCU release AND the association remains alive AND userspace can st...