net/ipv6/xfrm6_policy.c, relevant to Linux hosts, virtual machines, appliances, and potentially WSL 2 instances that run a kernel containing the affected code.The MSRC entry appeared at 1:42 a.m. Pacific time on August 9, 2026, and identifies the issue by its upstream fix title: “xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst().” That title is unusually literal. The Linux Netdev mailing list and the upstream networking tree show that Xiang Mei of Microsoft submitted the patch, and that the fix was included in an IPsec pull request accepted into the upstream networking tree in July.
What Microsoft’s public page does not currently supply is the information administrators need to make a patch decision: no CVSS score, no affected-product table, no Windows KB, no WSL version, no fixed kernel build, and no statement on exploitation. Those omissions matter here because an MSRC-assigned CVE can look like a Windows servicing event even when the vulnerable code lives entirely in a separately maintained Linux kernel component.
The bug is a double release on an IPv6 IPsec failure path
The vulnerable routine,
xfrm6_fill_dst(), constructs destination state for Linux XFRM, the kernel subsystem that implements IPsec policy and packet transformation. In the IPv6 path, the routine stores a pointer to a network device in
dst.dev, then takes a reference to that device with
netdev_hold().
It subsequently attempts to acquire the device’s IPv6 state through
in6_dev_get(dev). If that operation fails, the pre-fix code drops the network-device reference with
netdev_put()and returns an
-ENODEVerror. The problem is that
dst.devstill points to the device whose reference was just released.
Later cleanup treats that non-null destination-device pointer as a live held reference. It can therefore release the same network device a second time through the generic destination teardown path. The upstream patch’s entire functional change is to clear
dst.devafter the first release, preventing the later cleanup code from acting on stale ownership state.
This is a classic kernel lifetime-accounting failure: the code correctly frees an acquired reference in its local error path but fails to invalidate the field that tells downstream cleanup code a reference remains. The result can be a netdevice reference-count imbalance. Depending on timing and the object’s state, consequences can range from kernel warnings and cleanup failures to instability around network-interface teardown. The upstream materials do not establish a practical route to code execution, privilege escalation, or remote compromise, and Microsoft has not published such a claim.
That distinction should govern the response. A CVE number confirms that the issue is being tracked as a security defect; it does not, on its own, establish an emergency exposure comparable to a remotely reachable Windows service vulnerability.
The affected condition is more specific than “IPv6 is enabled”
CVE-2026-64580 sits in the IPv6 XFRM policy path, not in ordinary IPv6 connectivity. A system needs to be using the Linux kernel’s XFRM/IPsec machinery, and the error path is reached when the kernel cannot obtain IPv6 device state after it has already retained the underlying network-device reference.
That makes this materially different from a broad network-parser bug where merely receiving traffic is enough. The evidence in the upstream code points to a failure during destination-state construction and cleanup. Systems with no IPv6 XFRM/IPsec use are less likely to exercise the path, while hosts that manage IPv6 IPsec policies, dynamic interfaces, network namespaces, or rapidly changing virtual network devices deserve closer attention.
Containers do not turn this into a container-image patching exercise. XFRM and network-device lifetime management happen in the Linux host kernel. For container platforms, the relevant remediation target is the node kernel supplied by the operating system, cloud image, appliance vendor, or Kubernetes platform—not merely a refreshed application container.
The record also does not yet define which stable kernel lines have received backports. The upstream fix was collected in an IPsec update in July 2026, but that fact alone does not prove inclusion in every currently supported stable or long-term-support branch. Distribution security advisories and kernel changelogs remain the authoritative place to determine whether a vendor’s package contains the correction.
Why the Microsoft listing can mislead Windows administrators
The connection to Microsoft is real: the patch author’s affiliation is Microsoft, and Microsoft’s Security Response Center has assigned and published CVE-2026-64580. But neither fact means the Windows TCP/IP stack is affected.
The vulnerable source file is Linux code. Native Windows, Windows Server, and Hyper-V hosts do not execute Linux’s
xfrm6_fill_dst()routine as part of their own networking implementation. Organizations should therefore not go hunting for an August 2026 Windows cumulative update or a Windows Server KB that “fixes” this specific function. MSRC’s current listing provides no such update because it provides no Windows product or build mapping at all.
WSL 2 is the important exception for Windows estates. Microsoft’s WSL documentation states that WSL 2 runs an actual Linux kernel inside a managed virtual machine, whereas WSL 1 does not. A Windows endpoint or server with WSL 2 can therefore carry Linux kernel exposure that does not exist in the Windows host kernel itself.
That does not mean every WSL 2 installation is demonstrably vulnerable. Microsoft has not yet connected CVE-2026-64580 to a particular WSL release, kernel version, or servicing package, and the CVE entry contains no fixed-build table. It does mean that WSL 2 belongs in the asset-review scope, particularly where developers or administrators use IPv6, VPN tooling, IPsec, Kubernetes-in-WSL, network namespaces, or mirrored networking.
Microsoft documents
wsl --statusas a way to view WSL configuration and kernel information, while
wsl --updateupdates the WSL package and its kernel components. Those are sensible first checks, but an update should not be represented as a confirmed remediation for CVE-2026-64580 until Microsoft publishes a version mapping or release note naming the fix.
The missing version data is the story administrators should watch
MSRC’s publication currently gives this CVE a public identifier without the deployment metadata normally expected from a Microsoft security advisory. The page includes the generic Security Update Guide disclaimer but, at publication, does not identify severity, impact, exploit status, mitigations, workarounds, affected software, or available security updates.
That leaves two different operational tracks:
- Linux infrastructure teams should identify hosts with IPv6 IPsec or XFRM policy use, check their distribution or appliance vendor’s kernel advisory stream, and apply a kernel update once the vendor maps its package to the upstream fix.
- Windows teams should separate ordinary Windows endpoints from machines running WSL 2. Check WSL kernel servicing status, but do not treat this as evidence that Windows itself requires an out-of-band patch.
The code change is small, but its placement matters. It fixes ownership bookkeeping during a failure path, and it will be most relevant to systems that create or tear down IPv6 IPsec destination state under changing network conditions. Until Microsoft or Linux distributors publish fixed-build information, the responsible action is to track the kernel package—not to declare every Windows machine exposed.
References
- Primary source: MSRC
Published: August 9, 2026 at 8:42 AM UTC
Loading…
msrc.microsoft.com - Related coverage: kernel.googlesource.com
Loading…
kernel.googlesource.com - Related coverage: msrc.microsoft.com
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: spinics.net
Loading…
www.spinics.net - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: support.microsoft.com
Loading…
support.microsoft.com - Related coverage: codebrowser.dev
Loading…
codebrowser.dev - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: android.googlesource.com
Loading…
android.googlesource.com - Related coverage: android.googlesource.com
Loading…
android.googlesource.com - Related coverage: lists.openwall.net
Loading…
lists.openwall.net - Related coverage: techcommunity.microsoft.com
Loading…
techcommunity.microsoft.com - Related coverage: techcommunity.microsoft.com
Loading…
techcommunity.microsoft.com