The Microsoft Security Response Center entry provides the CVE identifier and publication time but, at publication, does not publicly expose a CVSS score, affected-product list, build numbers, mitigation, download, or revision history. The accessible NVD record likewise does not appear to have been published yet. That leaves the Linux kernel’s upstream commit as the most complete primary technical record—and it describes a narrow but real crash path in the networking stack.
This matters to WindowsForum readers because the MSRC listing can easily be misread as a Windows vulnerability. The submitted Microsoft record does not identify Windows, Windows Server, WSL, Hyper-V, or any specific Microsoft product as affected. Windows itself does not use the Linux XFRM implementation described here. A Windows PC running WSL 2 or a Linux virtual machine should therefore not be marked affected merely because the advisory is hosted by Microsoft; applicability depends on the guest kernel and whether it includes the flawed XFRM policy code.
The fault is in Linux IPsec policy rebuilding
XFRM is Linux’s packet-transformation framework, most visibly used by kernel IPsec. It maintains security policies that decide which traffic should be protected, bypassed, or rejected. For efficiency, the kernel organizes these policies in lookup structures that can be rebuilt when the policy hash needs to be resized or rearranged.
The bug concerns inexact policies: entries whose address prefixes are broad enough that they do not fit the normal exact-policy fast path. These policies are placed in separate bins. During
xfrm_hash_rebuild(), the kernel removes policies from their old positions and reinserts them into the rebuilt structures.
The intended design was sound. Before removing entries, the first pass was meant to allocate all bins and list nodes the later reinsertion pass would require. Once entries had been detached with
hlist_del_rcu(), reinsertion should have needed no allocation at all.
The implementation did the opposite for the policies that matter. According to the upstream fix written by Xiang Mei of Microsoft and reviewed by netfilter maintainer Florian Westphal, the preallocation condition was inverted. The code prepared bins for exact policies, which do not need them, while skipping the inexact policies that do.
That omission sends inexact-policy reinsertion into an allocation path using
GFP_ATOMIC. Such allocations cannot sleep and can fail when suitable memory is unavailable. The kernel recorded a warning on failure and continued, rather than restoring the removed policy entry or aborting the rebuild safely.
One failed allocation poisons the next rebuild
The practical failure sequence is more serious than a single failed lookup or a lost optimization.
After an inexact policy has been removed from its old hash chain, a reinsertion failure can leave its
bydstlist node in an invalid, poisoned state. The immediately affected rebuild may complete with only a warning. The next policy-hash rebuild can then try to remove that already-poisoned node, dereference the kernel’s
LIST_POISON2marker, and trigger a general-protection fault.
The upstream report includes a KASAN-observed crash in the XFRM workqueue path, ending in a kernel panic. In other words, the externally visible impact documented by the patch is denial of service: a running Linux system can crash when the triggering conditions align.
The commit says the condition is reachable under memory pressure and reproducible with the kernel’s
failslabfault-injection facility. That is useful evidence that the bug is not theoretical, but it is not the same as evidence of broad exploitation. No public exploit, exploitation-in-the-wild report, confidentiality impact, integrity impact, or privilege-escalation path was identified in the published MSRC record or in the upstream material reviewed for this report.
The distinction is important. This should be prioritized by teams operating Linux gateways, VPN endpoints, container hosts with complicated networking, and appliances that maintain large or changing IPsec policy sets. It is less urgent for a workstation or server that does not use XFRM/IPsec policy management at all, although the code can still be compiled into its kernel.
The upstream correction removes allocation from the dangerous phase
The patch is small, but its placement is decisive. It reverses the faulty test so the initial pass preallocates bins for exactly the inexact policies that will require them. When the kernel begins reinserting entries after detaching them from the old hash chains, the necessary bins already exist.
That changes the vulnerable sequence from:
- An inexact policy is detached from its existing hash chain.
- The kernel attempts an atomic allocation while reinserting it.
- A memory-allocation failure leaves the policy node poisoned for a later rebuild.
To:
- The kernel allocates the required inexact-policy bins before detaching existing entries.
- Reinsertion reuses already-created bins and does not allocate.
- The failure mode that poisons an entry between rebuilds is removed.
The fix is upstream commit
f38f8cce2f7e79775b3db7e8a5eacda04ac908e4, titled “xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert.” It identifies the older commit
24969facd704, “xfrm: policy: store inexact policies in an rhashtable,” as the origin of the flawed behavior. Kernel mailing-list archives place that earlier XFRM work in December 2018, which means the affected logic has existed upstream for years.
That age should not be converted into a blanket version claim. Distribution kernels selectively backport networking changes, carry vendor modifications, and may have adopted the original XFRM rework at different times. A distribution kernel version that looks old can have the fix; a newer-looking custom build can lack it. Commit presence, not a guessed kernel-version range, is the reliable test.
Microsoft’s listing is late and incomplete, not proof of Windows exposure
There is a notable documentation gap between the upstream Linux record and the new MSRC entry. The Linux patch was authored on July 3, committed by Steffen Klassert on July 6, and named in the IPsec pull request that reached the networking tree on July 10. Microsoft’s CVE page appeared almost a month later, on August 9.
The timing does not establish that Microsoft shipped a vulnerable Windows component, that WSL is affected, or that an out-of-band update is pending. It does establish that the CVE arrived after upstream maintainers had already accepted a concrete fix. The actionable remediation path is therefore downstream kernel packaging, not waiting for a generic Microsoft Knowledge Base article.
Microsoft’s page also does not say whether any Microsoft-maintained Linux distribution, Azure image, WSL kernel package, or container-host offering includes the corrected commit. That omission is material. Organizations using Microsoft-managed Linux images should look for a vendor advisory or package changelog that explicitly references CVE-2026-64579 or the upstream commit; neither the advisory title nor a Windows Update scan can answer that question.
What administrators should verify now
Start by identifying whether the systems in scope actually use Linux XFRM policies. IPsec gateways, route-based or policy-based VPN hosts, security appliances, Kubernetes or container nodes with custom networking, and hosts using
ip xfrmdeserve the first review. A standard Windows endpoint without a Linux guest is outside the implementation discussed in the upstream fix.
For Linux systems, inventory the running kernel and the installed kernel package separately. The package is what tells you whether a fix has been deployed; the running kernel is what tells you whether the machine has actually booted into it. Review distribution release notes and changelogs for the upstream commit ID, not only for the CVE number, because CVE metadata often arrives after a patch has been backported.
If the vendor has delivered the correction, reboot into the new kernel. Updating a package without rebooting leaves the vulnerable kernel resident. If no fixed package exists, reducing exposure means limiting use of dynamic XFRM/IPsec policy management on the affected host and avoiding avoidable memory-pressure conditions, but those are operational mitigations rather than a repair.
The immediate consequence is straightforward: organizations with Linux IPsec or XFRM deployments should treat CVE-2026-64579 as a patch-verification task. The upstream repair already exists; the unresolved question is which downstream kernels have actually carried it, and Microsoft’s newly published advisory does not yet supply that answer.
References
- Primary source: MSRC
Published: August 9, 2026 at 8:42 AM UTC
Loading…
msrc.microsoft.com - Related coverage: msrc.microsoft.com
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: kernel.googlesource.com
Loading…
kernel.googlesource.com - Related coverage: android.googlesource.com
Loading…
android.googlesource.com - Related coverage: nvlpubs.nist.gov
Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.4
The Security Content Automation Protocol (SCAP) is a suite of specifications that standardize the format and nomenclature by which software flaw and security configuration information is communicated, both to machines and humans. This publication, along with its annex (NIST Special Publication...nvlpubs.nist.gov
- Related coverage: kernel.googlesource.com
Loading…
kernel.googlesource.com - Related coverage: nvd.nist.gov
Loading…
nvd.nist.gov - Related coverage: nvd.nist.gov
Vulnerability APIs
nvd.nist.gov
- Related coverage: codebrowser.dev
Loading…
codebrowser.dev - Related coverage: cve.org
Loading…
www.cve.org - Related coverage: cve.org
Loading…
www.cve.org - Related coverage: test.cve.org
Loading…
test.cve.org - Related coverage: git.raptorcs.com
Loading…
git.raptorcs.com