A subtle netfilter change in the upstream Linux kernel — logged as CVE-2025-39764 — was introduced to remove unsafe reference-counting in the conntrack
expectation dump path, fixing a race that could lead to a kernel memory leak; Microsoft’s public attestation names
Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” but that statement is a scoped inventory result, not a blanket guarantee that other Microsoft products are unaffected.
Background
CVE-2025-39764 is an upstream Linux-kernel fix in the netfilter/ctnetlink code that altered how
expectation objects are handled during netlink dump operations. The change removes attempts to hold an expectation alive via refcounting in the dumper path and instead stores a cookie value to support dump resumption. The vulnerability is best described as a logic/race issue that can cause either a double‑increment / leak or an incorrect refcount sequence leading to resource exhaustion and a possible denial-of-service (kernel memory leak). Multiple distribution trackers (Debian, Ubuntu, SUSE, Amazon Linux advisories and others) have recorded the CVE and mapped it to affected kernel trees and fixed package releases where available. The vulnerability is considered
medium severity in multiple vendor advisories with a CVSS v3 score reported around 5.5 for the common deployment scenarios (local, low‑privilege attacker could cause a resource exhaustion denial-of-service).
What Microsoft has said (and what that means)
Microsoft’s Security Response Center (MSRC) published guidance that explicitly identifies
Azure Linux as a Microsoft product that “includes this open-source library and is therefore potentially affected,” and stated the company’s commitment to publish machine-readable CSAF/VEX attestations and to update CVE/VEX records if additional Microsoft products are later identified as carriers of the affected component. That communication is a
product-level attestation — it reflects Microsoft’s validated inventory at the time of publication rather than an exhaustive, always-complete scan of every Microsoft SKU. Put plainly: Microsoft’s attestation tells Azure Linux customers they have an authoritative, automatable signal to act on right now. Microsoft also stated it will expand those attestations if its internal inventories discover that other Microsoft products ship the same vulnerable upstream code. That procedural commitment is important, but it does not automatically prove absence of the component elsewhere at the time of writing.
Short answer to the user's question
No —
Azure Linux is not necessarily the only Microsoft product that could include the affected code, but it
is the only Microsoft product Microsoft has publicly attested as including the vulnerable kernel component so far. Other Microsoft-shipped Linux artifacts — most notably the Windows Subsystem for Linux (WSL2) kernel and Microsoft’s CBL‑Mariner artifacts (used as base images and host OS for some Azure infrastructure and container hosts) — are plausible places where the same upstream netfilter code could appear if the kernel builds include the same commit range or kernel configuration options. Microsoft has committed to update its VEX/CSAF attestations if additional products are discovered to contain the component.
Why other Microsoft products might be affected
- Microsoft ships several distinct Linux artifacts or kernels:
- Azure Linux (Azure-distributed images / azl3) — explicitly attested as potentially affected by MSRC.
- CBL‑Mariner / Azure host images — Microsoft’s internal distro, used as a container host base and for some managed infrastructure, is a likely carrier of upstream kernel code changes when Microsoft builds kernel packages for that distro. CBL‑Mariner CVEs are published through Microsoft’s Security Update Guide and have appeared in past kernel advisories.
- WSL2 kernel — Microsoft publishes a custom WSL2 Linux kernel repository and distribution; WSL’s kernel configuration is available in the public repo and can include netfilter and conntrack-related options. WSL historically built kernels with many netfilter/iptables capabilities, and more recent WSL kernel releases added module support and expanded netfilter-related configuration flags. If the WSL2 kernel version/config used on a Windows host contains the vulnerable commit or an affected upstream version, it could be impacted.
- The vulnerable code is upstream Linux kernel code (netfilter/ctnetlink). Any Microsoft product that ships a Linux kernel binary built from an upstream tree containing the vulnerable commits — and that has the netfilter conntrack/ctnetlink functionality compiled in — is potentially affected. That means you must consider both kernel version and kernel configuration to determine exposure. Distribution-level tracking already shows multiple Linux vendor kernels included or patched for CVE-2025-39764.
How to determine if your Microsoft-supplied instance is affected — practical checks
If you run any Microsoft-supplied or Microsoft-built Linux kernel (Azure VM images, CBL‑Mariner-based hosts, WSL2), perform these checks immediately to determine exposure.
- Identify the kernel and distribution:
- Run: uname -a
- Check distro release: cat /etc/os-release
- Inspect kernel config for conntrack/ctnetlink features:
- If /boot/config-$(uname -r) exists: grep -E 'NF_CONNTRACK|CTNETLINK|CONNTRACK' /boot/config-$(uname -r)
- If /proc/config.gz exists: zcat /proc/config.gz | grep -E 'NF_CONNTRACK|CTNETLINK|CONNTRACK'
- Check loaded modules (for module-built conntrack features):
- lsmod | grep conntrack
- modinfo nf_conntrack (if modules present)
- Map kernel version/commit to vendor security advisories:
- Compare uname output against vendor CVE advisories (Ubuntu, Debian, SUSE, Amazon Linux, CBL‑Mariner, Microsoft Azure Linux VEX/CSAF) to see if your kernel version sits inside the vulnerable range. Distribution trackers have already mapped fixed package versions; if your kernel is older than the fixed version, it is vulnerable until patched.
- For WSL2 users:
- Check the WSL kernel release: wsl -l -v (then open a distro and run uname -r)
- Microsoft publishes the WSL2 kernel repository and config; if you run the supplied Microsoft kernel and its release/tag is older than a patched upstream level, plan an update or build a patched custom kernel. The WSL kernel repo and release notes explain how Microsoft distributes kernel updates and how to use custom kernels.
Recommended mitigations and remediation steps
- Patch promptly:
- The canonical remediation is to install a vendor-provided kernel update containing the upstream fix for CVE-2025-39764. Use the update mechanism appropriate for the product:
- Azure Linux / Azure VM images: apply distro kernel security updates through your VM image update channels or the Azure marketplace recommended patching procedures. Microsoft has published Azure Linux attestations for CVEs and will publish fixes where applicable.
- CBL‑Mariner-based hosts: apply the CBL‑Mariner kernel patch(s) when vendor updates are published through Microsoft’s update guide / repository.
- WSL2: update Windows/WSL to the latest WSL kernel Microsoft ships via Windows Update, or build and configure a custom patched kernel and point WSL to it in %USERPROFILE%.wslconfig.
- Compensating controls (stopgap):
- Limit or restrict access to systems where unpatched kernels are used. The common attack scenario is local (low-privilege) so ensuring proper user separation, disabling untrusted user access or container runtimes, and applying host hardening reduces exploitability.
- Monitor / audit for syscalls/behaviour indicating conntrack dumping or abnormal kernel resource exhaustion. Because the issue is a memory/leak condition, watch kernel memory pressure and dmesg kernel logs for signs of resource exhaustion.
- Validate Microsoft attestations:
- Use Microsoft’s CSAF/VEX outputs (machine-readable attestations) for Azure Linux to programmatically determine whether a Microsoft product in your fleet is known-affected, not affected, under investigation, or fixed. Microsoft’s VEX rollout began by focusing on Azure Linux and will expand to more SKUs over time; integrate VEX/CSAF into your vulnerability automation to reduce false positives.
- For administrators of mixed environments (Azure + on-prem + Windows clients):
- Treat Microsoft’s Azure Linux attestation as an authoritative signal for Azure Linux, but independently validate other Microsoft artifacts in your estate (WSL hosts, CBL‑Mariner-based appliances, images used by AKS nodes) because Microsoft’s published scope is the starting point and subject to expansion.
Technical analysis: what the bug actually changes
The upstream fix (multiple small commits) removes a pattern in the ctnetlink dump code that attempted to increase an expectation object's refcount to keep it alive across a dump/resume window. The code previously used if (!refcount_inc_not_zero(&exp->use) semantics in the dumper path. That logic can misbehave in rare races where the object equals the dumped-last pointer or other boundary cases; the fix stops holding the object by refcount and instead stores a cookie that is used as a skip-hint for resuming a dump, mirroring a prior conntrack dumper fix. The root causes are subtle concurrency and lifecycle-management issues — classically a refcount-increment race leading to either double-increment or not properly releasing and thus leaking memory. Operationally, this vulnerability is not a remote code execution of the classic “wormable” type; it is a local vector that can cause memory leak and service disruption when exploited. That makes it priority-high for heavily multi-tenant systems where untrusted local users or containers exist (cloud VM hosts, shared systems), and medium for single-tenant systems with no untrusted local access. Multiple vendor trackers have assigned an AV:L/PR:L attack vector (local low-privilege) with an availability impact.
Microsoft-specific product notes
Azure Linux (explicit Microsoft attestation)
- Microsoft has published CSAF/VEX attestations starting with Azure Linux and declared Azure Linux includes the upstream component (netfilter) in question and is therefore potentially affected. This gives Azure customers a clear and machine-readable signal to automate detection and remediation in their Azure estates. Microsoft pledged to update the VEX/CSAF records if more Microsoft products are found to ship the same upstream library.
WSL2 kernel
- WSL2 runs a Microsoft-maintained kernel that is publicly available in a GitHub repository. The kernel configuration and release tags for WSL2 are public and have historically included netfilter-related features; module support was expanded in more recent WSL kernel releases and administrators can also supply a custom kernel. If the WSL2 kernel running on a Windows client is from an affected upstream version and includes conntrack/ctnetlink functionality, it should be treated as potentially vulnerable until patched. Microsoft distributes WSL kernel updates (and also allows custom kernels).
CBL‑Mariner and other Microsoft Linux artifacts
- CBL‑Mariner is Microsoft’s Linux distro for internal cloud/host/container usage and is already integrated into Microsoft’s update publication process. If CBL‑Mariner kernel packages include vulnerable upstream code, Microsoft will publish CVE mappings and updates through its security update channels. Historical CBL‑Mariner advisories show Microsoft’s mechanism and precedent for posting kernel CVEs managed via the Security Update Guide.
Evidence and cross-checks used for this analysis
- Upstream vulnerability descriptions and patch references in NVD and Linux kernel patch commits describe the behavioral change and the rationale for the fix.
- Multiple distribution trackers (Debian, Ubuntu, SUSE, Amazon Linux) have registered the CVE and linked the upstream commits; these trackers also show which distro kernel packages were patched or listed as vulnerable in specific releases (useful to map kernels to fixed versions).
- Microsoft’s MSRC blogs and the WSL2 kernel GitHub repository are public and show Microsoft’s published approach to CSAF/VEX attestations, plus the fact that Microsoft builds and distributes multiple Linux kernel artifacts (Azure Linux, CBL‑Mariner, WSL kernel). Those public artifacts and blog posts establish that Azure Linux is the first Microsoft product to receive a VEX attestation, and that Microsoft has a mechanism to expand that attestation scope as inventory work continues.
Caveats, unknowns, and what to watch for
- Microsoft’s attestation scope is a snapshot. When MSRC says “Azure Linux includes this open‑source library and is therefore potentially affected,” that is an authoritative statement about Azure Linux — but it is not a guarantee that Microsoft has finished inventorying every internal or partner-supplied SKU. Microsoft’s stated process is to expand the attestations as inventories complete, so customers should watch for updates to the CVE/VEX artifacts.
- Exposure depends on two factors: (1) whether a product ships a kernel built from an upstream commit range that contains the vulnerable code, and (2) whether the kernel build includes the netfilter conntrack/ctnetlink functionality (built-in or as modules). Both must be true for the product to be affected, so do not assume all Linux-using Microsoft artifacts are vulnerable — each artifact requires the two-part check above. Distribution advisories are the best way to map specific kernel package versions to fixed/unfixed status.
- Some Microsoft-managed services may not ship a Linux kernel to tenants (for example, certain PaaS services). For those services, the CVE is irrelevant in practice. For IaaS/VM images, however, the guest OS kernel matters, and many Azure VM images explicitly include vendor-provided kernels which you must patch via guest OS updates. Azure Linux VEX helps customers prioritize which Azure-provided images need action.
Recommended action checklist for administrators (quick reference)
- For Azure customers:
- Automate ingestion of Microsoft CSAF/VEX attestations for Azure Linux and correlate with inventory to find affected VM images. Apply vendor kernel updates to Azure Linux images and guest VMs as soon as patches are published.
- For CBL‑Mariner and Azure host operators:
- Subscribe to CBL‑Mariner security advisories and apply kernel updates according to Microsoft’s published package fixes.
- For WSL2 users and Windows admins:
- Check WSL kernel release (uname -r inside WSL). Update Windows/WSL to the latest WSL kernel image Microsoft ships or configure and install a patched custom kernel if necessary.
- For mixed estates:
- Use the kernel inspection steps above (uname, grep config, lsmod) across your fleet, correlate with distro security advisories (Debian/Ubuntu/SUSE/ALAS etc., and patch via standard OS update tooling.
Conclusion
Microsoft’s public message is clear and — crucially —
limited by scope: Azure Linux has been validated to include the upstream netfilter component responsible for CVE‑2025‑39764 and therefore is
potentially affected, and Microsoft will expand attestations if and when other Microsoft products are found to include the same upstream component. That does not logically equate to “Azure Linux is the only possible Microsoft product that can be affected.” Other Microsoft Linux artifacts — especially the WSL2 kernel and CBL‑Mariner-based images — are reasonable candidates for additional impact if their kernel versions/configurations include the vulnerable upstream code; administrators should therefore verify kernel versions and configurations, consult vendor advisories (including Microsoft’s VEX/CSAF outputs), and apply vendor-supplied kernel updates without delay. Being pragmatic: treat Microsoft’s Azure Linux attestation as an authoritative trigger to patch Azure Linux images now, and treat all other Microsoft-supplied kernels as
potential exposures until you’ve validated kernel versions and applied patches (or received an explicit VEX attestation from Microsoft declaring them “Not Affected” or “Fixed”).
Source: MSRC
Security Update Guide - Microsoft Security Response Center