A remote SCTP peer can trigger CVE-2026-64564 by sending a crafted ASCONF message over an established association with Dynamic Address Reconfiguration negotiated. The Linux CNA record says the peer needs no local credentials or capabilities. Tencent Zhuque Lab separately demonstrated a reliable path from an attacker-controlled local process to host root and container escape.
Those findings describe two supported scopes. The kernel record establishes a network-reachable trigger that can cause a use-after-free, crash, or potential kernel compromise. Tencent’s August 6 disclosure proves the complete privilege-escalation chain from a local process or workload on tested systems. The CNA added its detailed network scenario on August 9, making the distinction important as administrators map exposure and schedule fixed kernels.
Remote peers reach the bug
SCTP Dynamic Address Reconfiguration uses ASCONF chunks to add or remove network paths for an association. The vulnerable code caches the transport used to process a chunk. Its existing guard compares a deletion against the packet source address, although the cached transport can instead correspond to an address parameter inside the chunk.
An attacker sends one ordered ASCONF containing an address parameter, a deletion of that address, and a wildcard deletion. The first deletion frees the cached transport through RCU. The wildcard operation then reuses the dangling pointer, places it into the association’s primary and active path state, and removes the remaining valid transports.
No race is required.
The CNA scores the flaw 9.8 and assigns AV:N. Its scenario requires a remote SCTP peer that completes a normal association with ADD-IP negotiated. The peer can supply the SCTP authentication material through that handshake, or encounter a system using addip_noauth. The record says later dereferences can produce a kernel panic and may support memory disclosure or control-flow compromise.
Tencent proved the local chain
Tencent’s research begins from an attacker-controlled local process that can use SCTP on the vulnerable host. The lab says Corvus AI “developed the initial finding into a reproducible vulnerability and demonstrated local privilege escalation and container-to-host escape on the tested systems.”
Tencent demonstrated the local path.
The exploit reclaims the freed transport with a packet-socket ring buffer and obtains a kernel address leak. It turns that leak into a repeatable four-byte kernel read, locates the interrupt descriptor table, and defeats KASLR. A second use-after-free places attacker-controlled SCTP authentication-key data into the reclaimed memory.
The researchers then build a fake kernel object graph that reaches commit_creds. Their tests produced global root on Ubuntu 24.04, Debian 13, Rocky Linux 9, and kernels from 5.14 through a 7.2 release candidate. For container escape, they used per-socket SCTP options and report six successful escapes in eight attempts against containers with default seccomp profiles.
Figure details
The upper lane shows the Linux CNA scenario: a remote SCTP peer completes an association with ADD-IP negotiated, sends a crafted ASCONF sequence, and triggers a transport use-after-free that can crash the kernel or potentially compromise it. The lower lane shows Tencent's demonstrated chain from a local process or container workload: reclaim the freed object, leak a kernel address, construct a fake object graph, and reach global root or the host namespace. The sources do not demonstrate an end-to-end remote-to-root exploit.
Exposure follows two paths
Network exposure exists when an untrusted SCTP peer can establish an association with ADD-IP available and reach the vulnerable receive path. Local exposure exists when an untrusted process or container workload can access SCTP on the host. These paths can overlap, but administrators should inventory them separately.
The record does not quantify exposure.
Start with the kernel configuration, loaded-module state, active SCTP sockets, listening applications, firewall policy, and workload manifests. Determine whether SCTP is built into the kernel or loaded as a module. Identify systems that accept SCTP from untrusted networks and containers or local services that can create SCTP sockets.
The cited sources report no exploitation in the wild, victim count, or campaign indicators. Tencent demonstrates local root and container escape. The CNA’s network scenario documents the remote trigger and assesses potential privilege escalation, but neither source demonstrates a complete remote-to-root chain. Preserve that boundary in incident scoping.
Verify the running kernel
The upstream fix rejects a delete request when it targets the transport processing the current ASCONF operation. The CVE record identifies fixed stable releases 6.6.148, 6.12.101, 6.18.42, and 7.1.6, plus mainline 7.2-rc5. Later maintained releases on each affected branch supersede those first fixed versions.
The running kernel decides the result.
Distribution kernels often backport security fixes without matching upstream versions. Use the distribution’s CVE advisory and package changelog to identify its fixed build. Install the corrected package and reboot every server and container node. Then run uname -r on each node and compare the live build with the vendor’s fixed package. An installed package awaiting reboot does not close the vulnerable path.
When patching must wait, restrict unnecessary SCTP traffic and workload access. Removing an unused module can reduce reachability, but it cannot help when SCTP is built into the kernel. Confirm that temporary controls survive reboot and that an untrusted workload cannot reverse them. These controls reduce access while maintenance proceeds; they do not repair the use-after-free.
Reconstruct the vulnerable interval
Map both trigger surfaces before deciding that a host was merely patchable. Record which network peers could establish SCTP associations with ADD-IP, and which processes or workloads could open SCTP sockets. Preserve firewall changes, socket telemetry, kernel configuration, loaded modules, workload manifests, and node-pool history for the affected period.
Review journalctl -k for SCTP faults, use-after-free reports, sanitizer output, oopses, and unexpected reboots. Correlate active or historical SCTP sockets with process ancestry and container-runtime events. Host-namespace process creation following container activity deserves escalation, although its absence is meaningful only when the required telemetry was retained.
History still matters after reboot.
Verify each node’s running kernel, fixed-build status, and reboot time. Confirm that network policy blocks unauthorized SCTP peers and that workload policy limits local SCTP use where the protocol is unnecessary. The expected result is a vendor-fixed running kernel plus an explained set of SCTP associations and workloads during the exposure window.
If the host admitted either trigger path and retained evidence cannot bound its integrity, rebuilding the node and rotating host-readable secrets is a proportionate response. The reboot proves the fix is active. Only retained telemetry can speak for the vulnerable interval.