A memory-safety vulnerability hidden in the Linux kernel for almost two decades can allow a low-privileged user to take complete control of affected systems and, under certain conditions, escape from a container to compromise the underlying host.
Tracked as CVE-2026-64564 and named SCTPhantom, the vulnerability is a use-after-free flaw in Linux’s implementation of the Stream Control Transmission Protocol, or SCTP. The affected code handles dynamic changes to the network addresses associated with an SCTP connection.
Researchers at Tencent’s Zhuque Lab developed an exploit that converted the memory-corruption condition into reliable kernel-level privilege escalation. In tests, the researchers obtained root access on systems running Debian 13, Ubuntu 24.04, Rocky Linux 9 and Red Hat Enterprise Linux 9-family kernels, OpenCloudOS-based systems and a Linux 7.2 release-candidate research kernel.
The team also reported successfully escaping from a container without granting it the powerful CAP_SYS_ADMIN or CAP_NET_ADMIN capabilities normally associated with high-risk container configurations.
Linux kernel maintainers have released fixes across the supported stable branches. Administrators should update to a vendor-supplied kernel containing the correction rather than relying exclusively on the upstream kernel version displayed by the system.
Vulnerability Dates Back to Linux 2.6.25
The faulty SCTP processing sequence dates to a Linux kernel change completed for Linux 2.6.25, released in 2008. As a result, the vulnerable logic has been present in Linux for approximately 18 years.
Tencent researcher Fourie Zhang publicly disclosed SCTPhantom on August 6, 2026, following a coordinated remediation process with Linux kernel maintainers. The Linux CVE team had published the official CVE record on August 4.
According to Tencent’s disclosure timeline, researchers identified the underlying transport-lifetime violation on July 12 and began privately reporting the issue that day. They completed an initial stable root exploit by July 15, tested it across multiple kernel families between July 15 and July 23, and validated the container-to-host escape on July 27.
The fix was introduced into the Linux networking tree on July 24 before being distributed to maintained stable branches. The mainline correction is identified by commit 9b2854f86f0b.
The first fixed upstream releases are:
Linux 6.6.148
Linux 6.12.101
Linux 6.18.42
Linux 7.1.6
Linux 7.2-rc5
Enterprise Linux distributions frequently backport security patches while retaining an older-looking base kernel number. A Red Hat system using a 5.14-based kernel, for example, may eventually receive the correction without moving to Linux 6.x or 7.x. Administrators should therefore consult their distribution’s security tracker and package changelog rather than assessing exposure solely from the output of uname -r. Tencent Zhuque Lab’s technical analysis and the Linux security disclosure posted to oss-security list the affected and corrected kernel branches.
Understanding SCTP and Its Multihoming Support
SCTP is a message-oriented transport protocol designed for applications requiring reliable communication, ordered data delivery and resilience across multiple network paths.
Unlike a conventional TCP connection, an SCTP “association” can use several source or destination IP addresses. This multihoming capability allows communication to continue through another path when a network interface, route or address becomes unavailable.
Dynamic Address Reconfiguration, defined in RFC 5061, extends SCTP by permitting endpoints to add or remove addresses while an association remains active. It uses Address Configuration, or ASCONF, messages containing operations such as ADD-IP, DEL-IP and SET-PRIMARY.
Linux represents the remote paths belonging to an SCTP association using sctp_transport structures. It also maintains references identifying the association’s primary and currently active paths. Those references are expected to point only to valid transport objects that remain attached to the association.
SCTPhantom violates that expectation.
Address Confusion Creates a Dangling Kernel Pointer
The vulnerability arises because the Linux SCTP implementation can use two different addresses while validating and processing the same ASCONF message.
One address is the source address of the received packet. A second address appears inside the ASCONF message and is used to select the transport against which the message will be processed.
The kernel stores a pointer to that selected transport in asconf->transport. However, when processing a request to delete an address, the existing safety check compares the deletion target with the packet’s source address—not necessarily the transport cached in asconf->transport.
An attacker can exploit this mismatch by constructing a single ASCONF message with a carefully ordered sequence:
[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]
In this sequence, the internal address L differs from the packet’s source address. The request to delete L therefore passes the source-address protection. Linux removes the associated transport object, but asconf->transport continues to point to the object that has just been scheduled for release.
The wildcard deletion using 0.0.0.0 then causes the kernel to reuse that stale pointer. The deleted transport can be installed as the association’s primary and active path even though it no longer belongs to the live transport list.
This is known as a use-after-free: software releases a memory object but continues using a pointer to its former location. If an attacker can cause controlled data to occupy that memory, later kernel operations may interpret the attacker’s data as a legitimate internal object.
At a minimum, such a condition can produce a kernel crash or denial of service. Tencent’s research demonstrated that SCTPhantom can be developed considerably further, producing information-disclosure primitives, bypassing kernel address randomisation and ultimately executing a privileged kernel operation.
The official CVE record for CVE-2026-64564 classifies the issue as a Linux SCTP transport use-after-free. The Linux patch adds a direct check that rejects a deletion when the targeted peer is the same transport retained for processing the ASCONF message.
The correction is small, but it closes the identity mismatch responsible for the vulnerability.
From Memory Corruption to Full Root Access
Triggering a use-after-free is only the beginning of an exploit. To obtain root access, an attacker must control or predict what replaces the released kernel object and then turn subsequent accesses into useful operations.
Tencent’s exploit first establishes a multihomed SCTP association and arranges for a confirmed secondary path to become the target of the faulty deletion sequence. The association must remain alive long enough for the kernel’s Read-Copy-Update mechanism to finish releasing the transport while userspace retains a way to reach the dangling path.
The researchers then reclaimed the freed sctp_transport memory with a pg_vec array associated with a TPACKET transmit ring. When Linux subsequently handled an SCTP status request, it interpreted selected page pointers from the replacement allocation as fields belonging to the original transport.
That type confusion disclosed a kernel direct-map address for a page also mapped into the attacking process. The attacker could consequently manipulate data through the userspace mapping while referring to it using a valid kernel address.
Tencent then transformed the dangling transport into a repeatable four-byte arbitrary-read capability. That primitive was used to recover the kernel’s randomised address layout by reading information associated with the Interrupt Descriptor Table.
Kernel Address Space Layout Randomization, or KASLR, is intended to make exploitation more difficult by changing the locations of kernel code and data. Recovering the KASLR offset allowed the researchers to calculate the runtime address of security-sensitive kernel functions.
A second vulnerable SCTP association was then used to position a controlled object graph in place of another released transport. The final chain redirected an SCTP address-family callback to the kernel’s commit_creds() function, replacing the process’s credentials with privileged credentials.
The exploit did not require injecting conventional userspace shellcode into the kernel or constructing a traditional return-oriented programming chain. It reused legitimate kernel functions and manipulated kernel objects to produce the required change in credentials.
Tencent verified global root access by reading /etc/shadow and creating a root-owned file under /root, providing stronger evidence than merely observing a changed user identifier. The laboratory’s full analysis documents the exploitation stages and test results.
Container Escape Raises the Potential Impact
Containers isolate processes primarily through Linux namespaces, control groups, capabilities and security filters, but all containers running on a host normally share the same Linux kernel.
A container escape vulnerability does not have to defeat a separate hypervisor. If code inside a container can exploit the shared kernel, it may be able to cross namespace boundaries and affect the host itself.
Tencent initially believed the SCTPhantom chain would require the SCTP settings net.sctp.addip_enable and net.sctp.addip_noauth_enable to be enabled. Changing those system-wide settings would generally require CAP_NET_ADMIN, significantly limiting the number of exploitable container configurations.
The researchers later found that an application could request the necessary SCTP functionality for an individual socket using the SCTP_ASCONF_SUPPORTED and SCTP_AUTH_SUPPORTED options. The malicious trigger could then carry a valid SCTP authentication chunk without modifying the global sysctl settings.
In Tencent’s retained container test, the default seccomp profile remained enabled and the container received neither CAP_NET_ADMIN nor CAP_SYS_ADMIN. The researchers reported reaching host-level root access in six of eight attempts.
Instead of ending with commit_creds(), the container variant redirected execution to call_usermodehelper_exec(). The resulting kernel helper operated in the host’s initial namespaces, allowing it to perform a root-level filesystem operation outside the container.
The two unsuccessful attempts reportedly ended as clean pointer-walk misses and did not crash the kernel.
These results remain Tencent’s own laboratory findings. The disclosure does not identify the container runtime or version used, and independent researchers have not publicly reproduced the full escape chain. Actual exposure can differ significantly depending on whether SCTP is present, whether the relevant socket operations are available, and how the runtime configures seccomp, Linux Security Modules, user namespaces and capabilities.
A container should therefore not be considered automatically exploitable merely because the host kernel contains the vulnerable code. Nevertheless, the successful tests demonstrate that an unprivileged-looking container configuration may not be sufficient protection when the SCTP attack surface is accessible.
Tested Across Major Linux Distributions
Tencent reported obtaining root access on the following test targets:
Debian 13 with kernel 6.12.95+deb13-amd64
Ubuntu 24.04 with kernel 6.8.0-134-generic
Rocky Linux 9 and RHEL 9-family systems using a vendor 5.14 kernel with SCTP loaded
An OpenCloudOS-family system using kernel 6.6.119
A Linux 7.2-rc2 research kernel
The results show that the issue is not confined to one distribution, recent kernel generation or packaging model. It affects the common upstream SCTP implementation inherited by numerous Linux-based platforms.
However, exploit reliability and the exact heap-manipulation strategy can vary between kernel builds. Changes in structure sizes, allocator behaviour, hardening options and distribution-specific patches may require the exploit to be adapted.
Severity Scores Reflect Different Attack Assumptions
Tencent assigned SCTPhantom a CVSS 4.0 score of 8.5, rating it High severity. Its vector treats the demonstrated exploit as a local, low-privilege attack requiring no user interaction and potentially compromising all confidentiality, integrity and availability within the kernel.
The CVE record was subsequently enriched with a CVSS 3.1 score of 9.8, based on a network attack interpretation. That assessment reasons that the vulnerable code processes received SCTP ASCONF messages and that an SCTP peer capable of establishing a suitable association and negotiating the required functionality could deliver the malicious sequence over a network.
This distinction is important. Tencent’s published, end-to-end root and container-escape chains are locally initiated exploits. The presence of a theoretically network-reachable packet-processing path does not by itself establish that the complete privilege-escalation chain can be executed remotely in typical deployments.
Exposure depends on SCTP availability, network reachability, association establishment, dynamic-address support and authentication conditions. Security teams should therefore evaluate both the technical reachability of the vulnerable handler and the more thoroughly demonstrated local privilege-escalation scenario.
As of August 8, 2026, no public evidence indicated that CVE-2026-64564 had been exploited in real-world attacks, and it was not listed in the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities Catalog. A full weaponised exploit had also not been publicly released.
Absence from the KEV catalog does not mean a vulnerability is safe to defer. It means CISA has not added it based on evidence of exploitation in the wild.
How Organisations Should Respond
Administrators should install the corrected kernel packages supplied by their Linux distribution and reboot affected systems so the patched kernel becomes active. Installing a package without restarting leaves the vulnerable kernel running in memory.
Infrastructure teams should identify hosts on which the SCTP module is loaded, available for automatic loading or required by an application. Particular attention should be given to shared container hosts, multi-tenant systems, telecommunications infrastructure and servers on which untrusted or partially trusted users can run code.
Where SCTP is not required, organisations can reduce the attack surface by preventing the module from loading. That decision should be tested carefully because SCTP remains important in some telecommunications, signalling and specialised high-availability environments.
Container operators should review whether workloads can create SCTP, raw or packet sockets and whether their seccomp profiles block unneeded socket families and operations. They should also evaluate Linux Security Module policies and avoid assuming that removal of broad administrative capabilities alone eliminates exposure.
Security teams should verify remediation through the distribution’s package advisory or by confirming that the vendor kernel includes the relevant backported commit. The visible upstream version number is not, on its own, a reliable indicator.
AI-Assisted Research Uncovers a Long-Dormant Kernel Bug
Tencent credited the discovery and exploit-development process to Corvus AI, a multi-agent vulnerability-research pipeline created by the TencentOS Security Team and Zhuque Lab.
According to the researchers, the system divided kernel research into bounded tasks covering source review, packet generation, virtual-machine testing, crash triage and exploit development. It preserved evidence and constraints between experiments, allowing different agents and models to continue the investigation without losing earlier findings.
Corvus AI did not simply identify a suspicious code pattern. Tencent said it helped advance the issue from an initial soft lockup to a reproducible post-RCU use-after-free, a cross-distribution root exploit and finally a container-to-host escape.
SCTPhantom illustrates why obscure, mature kernel subsystems remain a significant source of security risk. Code can survive years of conventional review when exploitation depends on an unusual combination of protocol state, parameter ordering, object lifetime and memory-reclamation behaviour.
The vulnerability’s 18-year lifespan also shows that age is not evidence of safety. In complex stateful code, a small mismatch between the object being validated and the object being modified can remain invisible until researchers—or increasingly persistent machine-assisted research systems—trace the complete sequence from network message to memory lifetime and privilege boundary.