The upstream Linux fix, authored by Jun Yang and merged as commit
9b2854f, confirms the underlying defect: a specially arranged SCTP ASCONF message can remove the same peer transport object that the kernel has cached for processing the message, then cause later operations in that message to reuse the stale pointer. That is a classic use-after-free condition in kernel networking code.
Microsoft’s record is unusually thin for a vulnerability appearing in its update catalog. The page supplied for CVE-2026-64564 exposes the title and generic Security Update Guide disclaimer but no severity, CVSS vector, affected-product table, mitigation, workaround, or update mapping. The supplied timestamp also deserves attention: it says August 9, 2026, at 01:41:39 -07:00, which converts to 08:41:39 UTC—75 minutes after the current time of 07:26 UTC on August 9. That makes the record’s publication timing impossible to independently confirm from the visible metadata.
The SCTP ASCONF bug is a stale-pointer problem
SCTP, or Stream Control Transmission Protocol, is a transport protocol with multihoming support: an association can track more than one peer IP address. Its ASCONF messages permit dynamic address changes, including adding an address, removing an address, or choosing a primary path. Those capabilities are not used by most ordinary desktop workloads, but they are meaningful in telecom, clustered systems, specialized networking appliances, and applications built around SCTP’s multistreaming and multihoming features.
The vulnerable path begins when the kernel receives an ASCONF control chunk and caches the transport object associated with it in
asconf->transport. Normally, the kernel rejects an instruction to delete the packet’s source address. That protection is required by the SCTP ADD-IP specification and is already implemented as a source-address check.
The problem is that the cached transport does not always represent the packet’s source address. If an ASCONF message is located through an Address Parameter, the cached transport can correspond to the address named in that parameter instead. The upstream commit explains that an attacker can arrange a message with an Address Parameter for one address, followed by a DEL-IP command targeting that address, followed by a wildcard DEL-IP command.
The first DEL-IP passes the existing source-address protection because the target is not the packet source. It removes the cached transport. The following wildcard operation then continues to use
asconf->transport, which is now dangling. According to the upstream commit message, that later processing can dereference the freed object, set the association’s primary and active path pointers to it, and remove legitimate remaining transports from the association.
This is more than a malformed-packet rejection issue. Once kernel code retains a pointer to freed memory, the eventual result depends on allocator behavior, timing, kernel hardening, and what memory has been reused. It may manifest as a crash, SCTP association corruption, or a security-relevant memory-safety primitive. The upstream patch is narrowly targeted because it blocks the invalid deletion before the stale reference can be created.
The upstream fix has landed, but package coverage is the operational question
The Linux networking tree merged the fix into upstream development as
9b2854f, titled “sctp: don't free the ASCONF's own transport in DEL-IP processing.” The commit is marked for stable-kernel consideration and identifies an older SCTP wildcard ADD-IP change,
42e30bf3463c, as the introducing commit.
The actual code change is small: alongside the existing check that rejects deletion of the ASCONF packet’s source address, the kernel now rejects deletion of the IP address belonging to the transport currently handling that ASCONF message. In practical terms, Linux refuses a DEL-IP request that would invalidate the object its own ASCONF-processing path still needs.
That small patch is a warning against treating this as a low-consequence correctness fix. Kernel vulnerabilities often receive one-line remediations precisely because the dangerous state transition is easy to describe once found. Here, the vulnerable state is straightforward: delete a transport, retain its pointer, and make later code believe it remains a valid member of the association.
The important deployment fact is that upstream inclusion does not mean a particular installed kernel already contains the change. Enterprise distributions backport security fixes to long-lived kernels without changing the visible upstream version number, while custom appliances and vendor kernels may lag even after the upstream tree has been patched. Administrators should look for their distribution or appliance vendor’s advisory and verify that its supplied kernel package includes the SCTP ASCONF DEL-IP fix, rather than assuming a generic kernel-version comparison settles the question.
At publication time, no independently verifiable vendor advisory found during review establishes the complete set of fixed distribution builds for CVE-2026-64564. The upstream patch’s stable designation signals that backports are expected, but it is not a substitute for a package-level confirmation from Red Hat, Canonical, SUSE, Debian, a cloud-image provider, or an appliance vendor.
Windows systems are exposed only where they run a vulnerable Linux kernel
The MSRC listing can mislead a Windows-focused patch team into looking for a Windows Update that does not appear to exist. The available technical record instead points to
net/sctpin the Linux kernel. Native Windows networking is not shown as affected by the supplied Microsoft entry, and Microsoft has not published a Windows build number, KB identifier, or update package for this CVE.
The Windows relevance is indirect but real in mixed environments:
- Windows Server hosts running Linux virtual machines should treat the guest kernel as the patch target; updating the Hyper-V host alone does not replace the guest’s Linux kernel.
- WSL 2 users run a real Linux kernel in a lightweight virtual machine, so organizations that use WSL for development, CI, security tooling, or container work should determine the kernel build in use and whether SCTP is enabled.
- Windows container hosts running Linux containers depend on a Linux kernel layer, but exposure depends on the host or VM kernel, the runtime architecture, and whether SCTP is available to workloads.
- Azure, VMware, and other virtualized Linux estates require the same guest-image review as physical Linux systems. A Windows management plane does not change the vulnerable code path.
This is also a case where simple port scanning provides an incomplete answer. SCTP must be compiled and enabled, and an affected endpoint must process the relevant ASCONF traffic in an SCTP association. An organization that does not run SCTP applications may have little practical exposure, but “we do not intentionally use SCTP” is not proof that the protocol is unavailable. Kernel configuration, loaded modules, application dependencies, and container privileges all matter.
Administrators can start with three checks: establish whether
CONFIG_IP_SCTPis enabled in the running kernel, identify whether the SCTP module is loaded or can be loaded, and inventory services that create SCTP sockets. On systems where SCTP is not required, disabling or blacklisting the module can reduce attack surface while a vendor package is pending. That is containment, not remediation; the durable fix is a kernel package containing the upstream change.
Microsoft’s listing currently supplies a CVE, not an actionable Windows bulletin
The most consequential finding is what the Microsoft record leaves out. It gives Windows patch-management tooling a CVE identifier but, based on the page content available here, does not provide the information needed to turn that identifier into a Windows servicing action: no affected software, no severity rating, no known-exploitation assessment, no remediation instructions, and no KB.
That omission is especially significant because Microsoft Security Update Guide entries normally connect a vulnerability to affected products and updates when Microsoft servicing is involved. Here, the technical evidence resides in the Linux kernel’s SCTP code and its upstream patch. The correct owner for remediation is therefore the Linux distribution, cloud-image, appliance, or subsystem-kernel supplier—not Windows Update unless Microsoft later publishes a product-specific update mapping.
For now, Windows administrators should keep CVE-2026-64564 out of the normal “install this month’s Windows cumulative update” queue and place it in Linux guest, WSL 2, container-host, and appliance-kernel triage. The concrete action is to identify every Linux kernel under Windows administration that can run SCTP, then verify the vendor’s fixed package before treating the Microsoft catalog entry as closed.
References
- Primary source: MSRC
Published: August 9, 2026 at 8:41 AM UTC
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: msrc.microsoft.com
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: nvd.nist.gov
- Related coverage: nvd.nist.gov
- Related coverage: kernel.googlesource.com
- Related coverage: kernel.googlesource.com
- Related coverage: gitlab.com
net/sctp/sm_make_chunk.c · v2.6.32-rc3 · cip-project / cip-kernel / linux-cip · GitLab
CIP kernel mirror
gitlab.com
- Related coverage: learn.microsoft.com
Get vulnerability by ID - Microsoft Defender for Endpoint | Microsoft Learn
Retrieves vulnerability information by its ID.learn.microsoft.com - Related coverage: learn.microsoft.com
Export software vulnerabilities assessment per device - Microsoft Defender for Endpoint | Microsoft Learn
The API response is per device and contains vulnerable software installed on your exposed devices and any known vulnerabilities in these software products. This table also includes operating system information, CVE IDs, and vulnerability severity information.learn.microsoft.com - Related coverage: advisories.ncsc.nl
- Related coverage: cve.org
- Related coverage: first.org
