A small, targeted kernel bug in the Linux netfilter code — tracked as CVE-2025-38639 and described upstream as “netfilter: xt_nfacct: don't assume acct name is null-terminated” — has been fixed in upstream kernels and mapped by multiple distributions; Microsoft’s published guidance specifically
attests that Azure Linux includes the implicated component and is therefore
potentially affected, but that attestation is product-scoped and not definitive proof that other Microsoft products cannot contain the same vulnerable code.
Background / Overview
The vulnerability CVE-2025-38639 arises from an unsafe assumption in the netfilter xt_nfacct code path that an account name is NUL-terminated. The symptom reported in KASAN traces was a slab out‑of‑bounds read triggered during string formatting (vsnprintf) when the vulnerable path processed a non‑NUL‑terminated name. Upstream maintainers corrected the code to avoid relying on NUL termination and to prevent the out‑of‑bounds access. Multiple downstream trackers and Linux distributions mapped the fix and published advisories and backports in vendor kernels and packages. Distributors such as Amazon Linux and Ubuntu recorded package-level mappings and issued fixes for specific kernel tracks; scanning feeds list affected kernel trees and recommended updates. The public exploitability scoring has been modest so far (low EPSS and medium distribution-assigned severities), reflecting that the practical impact is a local or limited attack vector with availability effects (kernel memory corruption or potential DoS) rather than a widespread remote code execution chain. Why this matters to operators: the Linux kernel is a build‑time artifact. The same upstream source code can appear across many different kernel builds and vendor images depending on kernel version, backports, and build-time configuration (CONFIG options). That means
where the kernel binary is shipped matters; a CVE in the upstream source affects any product that ships a kernel built from the vulnerable commit range with the relevant code compiled in.
What Microsoft has published — reading the language carefully
Microsoft’s Security Response Center (MSRC) has adopted a machine-readable attestation model (CSAF/VEX) and began publishing VEX attestations for product families beginning in October 2025. For CVE-2025-38639, MSRC’s guidance contains the explicit sentence that “Azure Linux includes this open‑source library and is therefore potentially affected,” and MSRC also states it will update the CVE/VEX attestation if additional Microsoft products are discovered to ship the same upstream component. That phrasing is intentionally product-scoped: it is an authoritative inventory result for Azure Linux artifacts at publication time, not an assertion that no other Microsoft product could ever include the same code. Microsoft’s transparent VEX/CSAF rollout is significant because it gives customers a machine‑actionable signal — a clear “Known Affected / Not Affected / Under Investigation / Fixed” mapping for
each product named in the attestation. At present, Azure Linux is the product Microsoft chose to inventory and publish first; the company has publicly committed to expand attestations to additional product families over time. That operational model explains the narrow phrasing in MSRC advisories and why “Azure Linux includes the library” is the exact wording used. This is not a Microsoft-specific nuance: other large vendors adopt phased VEX rollouts because inventorying every binary, image, and embedded artifact across a massive product catalogue is time- and resource‑intensive. The practical consequence for defenders is that an attested product is a
confirmed hit and must be remediated without delay, while non‑attested products must be treated as
unverified until either a vendor attests them or the customer performs artifact-level verification.
Short, authoritative answer to the user’s question
No —
Azure Linux is not necessarily the only Microsoft product that could include the affected open‑source code. It is, however, the only Microsoft product Microsoft has
publicly attested (via MSRC’s CSAF/VEX outputs) as including the implicated component for CVE-2025-38639 at the time of the advisory. Absence of a VEX attestation for other Microsoft products is
not proof those products are clean; it means Microsoft has not yet published a product-level inventory for them. Microsoft has stated it will update its CVE/VEX records if additional Microsoft products are discovered to carry the component.
Why the distinction matters: product attestation vs. exhaustive scanning
- A VEX/CSAF attestation is a snapshot of the vendor’s inventory work for a named product family. When Microsoft says Azure Linux includes the component, that is the result of Microsoft inspecting the Azure Linux build artifacts and finding the component. It is a high‑fidelity signal for that product.
- Microsoft’s MSRC phrasing deliberately avoids claiming exclusivity. The company explicitly promises to update CVE records if further internal inventories find the same component in other Microsoft SKUs. That procedural commitment is important, but it does not equate to blanket assurance across the entire Microsoft product portfolio.
- For defenders and auditors, the practical difference between “attested” and “not attested” collapses to two operational actions: (1) if a product is attested as affected, remediate immediately per vendor guidance; (2) if a product is not attested, perform artifact-level verification (SBOMs, image scanning, binary inspection) to confirm presence or absence of the vulnerable code.
Which other Microsoft artifacts could plausibly include the vulnerable kernel code?
While Azure Linux is the only product attested so far, several Microsoft-maintained or Microsoft-distributed artifacts are plausible carriers because they ship Linux kernels or kernel-based images. These require targeted verification:
- WSL2 kernel images — Microsoft ships a custom WSL2 kernel (the microsoft/WSL2-Linux-Kernel repository) and publishes prebuilt WSL kernels to Windows updates and GitHub. If a WSL2 kernel build uses an upstream tree or backport that contains the vulnerable xt_nfacct code and the kernel config enables the netfilter xt_nfacct code, that WSL instance could be affected. Historically, WSL kernels have included many netfilter/iptables capabilities.
- linux-azure / kernel builds used in Azure VM images — Azure publishes multiple kernel configurations and VM images. Some Azure VM images use distributor kernels; others use Microsoft-built kernels. Any kernel binary built from an upstream commit range including the vulnerable code and compiled with the relevant netfilter options would be a potential carrier.
- CBL‑Mariner lineage artifacts beyond the base “Azure Linux” images — Microsoft’s internal CBL‑Mariner artifacts are the basis for Azure Linux images and appear in container host images, node images, and other infrastructure. Variants derived from the same lineage can exhibit different kernel packaging choices; verify precise image artifacts.
- Marketplace images, partner appliances, and container images — Marketplace images often include vendor-customized kernels or layered images built on top of other base images. A marketplace VM image or a partner appliance could bundle an older kernel or a kernel variant that contains the vulnerable code even if the Azure Linux base image is already patched.
Practically speaking,
any Microsoft product that ships a Linux kernel binary compiled from an affected upstream tree and with the xt_nfacct functionality enabled should be considered a candidate for verification until proven otherwise. Microsoft’s VEX rollout is designed to enumerate these product-by-product over time.
How to confirm exposure in your environment — step-by-step checklist
- Find the kernel version and build provenance for the target artifact.
- For VMs and container hosts, inspect the running kernel (uname -a) and consult your image’s release notes or SBOM. For Windows WSL instances, check the WSL kernel version shipped and whether the custom WSL kernel in use was replaced by an updated build. Knowing the exact kernel version and the disto’s backport policy makes the difference between “affected” and “fixed.”
- Verify whether xt_nfacct (and related netfilter modules) are present or compiled in.
- Check kernel config for CONFIG_XT_NFACCT or related netfilter options. If the component is built as a module, verify whether the module is present in /lib/modules/$(uname -r). If the code is not compiled in and the module is absent, the kernel binary cannot be affected. This is a build-time property.
- Check SBOMs, image layers, and binary contents for shipped kernels.
- For Azure Marketplace images and container images, inspect the image layers to find which kernel package or kernel binary is included. Use SCA/SBOM tooling to search for the kernel package name and upstream commit IDs. Microsoft’s VEX/CSAF artifacts for Azure Linux are machine-readable and can be consumed to automate part of this triage.
- If vendor attestations exist, cross‑validate.
- If Microsoft’s VEX/CSAF attests a product as “Known Affected,” treat that product as in-scope for immediate remediation. For other products, consult vendor advisories (distributor CVEs) and public trackers (NVD, OSV) to map upstream fixes to your package versions. Use at least two independent sources to validate the mapping before deferring action.
- Perform pragmatic mitigations if verification will take time.
- If you cannot immediately confirm or patch an artifact, apply compensating controls: reduce local administrative access, restrict unprivileged packet injection interfaces (raw sockets, TUN/TAP), limit access to container hosts, and increase monitoring for kernel oops, KASAN reports, or unexpected restarts. These are temporary risk-reduction measures while you push updates.
Remediation guidance and operational steps
- Apply vendor kernel updates or backports immediately for attested products.
For Azure Linux artifacts, follow Microsoft’s update guidance and apply the kernel packages or image updates Microsoft publishes via the Azure update channels. Microsoft’s VEX entries will be updated when fixes are available.
- For third‑party distributions, install the fixed kernel or vendor backport.
Distribution advisories (Amazon Linux, Ubuntu, SUSE, Debian) list which kernel branches contain the upstream fix and indicate whether the distro shipped backports. Align your remediation with the distribution guidance relevant to your image.
- Rebuild static or embedded images compiled from affected kernel sources.
If you maintain custom images or appliances that embed kernel binaries, rebuild those artifacts using patched kernel trees or updated distro base images. Static artifacts do not benefit from host package updates; image rebuilds are the only reliable fix path.
- Validate fixes experimentally.
After patching, monitor kernel logs for the absence of KASAN reports and run targeted test cases (if applicable) to exercise the netfilter paths that previously triggered the issue. Use sanitized builds (KMSAN/KASAN) in test environments if you need strong verification before deploying to production.
- Automate future attestation ingestion and triage.
Ingest vendor CSAF/VEX outputs (including Microsoft’s feed) into vulnerability triage pipelines. Automating “if product == Azure Linux and CVE == X then remediate” will drastically reduce time-to-fix for vendor-attested products. Microsoft’s VEX/CSAF files are machine-readable for this reason.
Risk analysis: severity, attack surface, and practical exploitability
Technically, CVE-2025-38639 is a kernel memory safety defect that was detected via sanitizer tooling (KASAN) and traced back to an assumption about string termination in xt_nfacct code paths. The common exploit scenario described by vendors is one where an attacker with local access or with the ability to inject crafted packets or netlink messages triggers the invalid memory read, potentially causing kernel memory corruption and a denial‑of‑service (panic or OOPS). Public trackers have placed the severity in the
medium range with CVSS and vendor-assigned scores between roughly 4.4 and 5.5 depending on vector and local access assumptions. Why exploitability remains limited in practice:
- The attack vector is often local or requires the ability to present netfilter inputs that exercise xt_nfacct; many cloud workloads do not expose those interfaces to untrusted tenants without additional misconfigurations.
- Kernel-level memory corruption is serious, but without an obvious remote, unauthenticated chain to trigger the path across network boundaries, the immediate risk for untargeted mass exploitation is lower than for a remotely exploitable networking daemon vulnerability.
Nevertheless, the typical enterprise posture should be conservative: treat medium-severity kernel memory bugs as high-priority for tenant isolation hosts, multi‑tenant nodes, container hosts, and development systems exposed to untrusted users because the blast radius (kernel instability, reboots, or DoS) is operationally impactful.
Practical case examples and what to check in Microsoft environments
- If you run Azure Linux VMs (the product Microsoft attested): Microsoft’s attestation is authoritative for those images; apply Azure Linux kernel updates and follow the VEX/CSAF records for remediation timelines. Use Azure image update channels and ensure any custom images built on Azure Linux are rebuilt from patched bases.
- If you run Windows Subsystem for Linux (WSL2): inspect the WSL2 kernel version and configuration. If you are using Microsoft-provided WSL kernels, check WSL release notes or the WSL2 kernel repo for published fixes. If you run custom WSL kernels or have manually replaced WSL kernels on machines, rebuild or update those kernels to include the upstream fix.
- If you operate Azure Kubernetes Service (AKS) or container nodes that use Azure Linux container-host images: verify the node image lineage, and apply patched node images or kernel updates as directed. Azure’s documentation notes the lifecycle of Azure Linux node images and stresses that container hosts receive kernel support updates; track node image EOL and update windows closely.
- If you use Marketplace or partner images: do not assume Azure Linux remediation automatically covers marketplace images. Each Marketplace/partner image is a distinct artifact and should be inventoried and scanned independently.
Strengths and limits of Microsoft’s VEX/CSAF approach (critical analysis)
Strengths:
- Machine-readable attestations reduce uncertainty. VEX/CSAF files let customers automate narrow, deterministic triage decisions for the named products. Microsoft’s initial rollout starting with Azure Linux is therefore a useful, pragmatic start.
- Procedural transparency — Microsoft’s public commitment to expand attestations and update CVE records if more products are found to carry the same component is a valuable operational promise that improves long-term supplier transparency.
Risks and limitations:
- Phased rollouts leave verification gaps. A phased VEX rollout necessarily means some Microsoft SKUs remain un‑attested for any given CVE at publication time. That creates an interval in which defenders must either trust their own artifact inspection or await vendor attestations. Absence of attestation is not a guarantee of safety.
- Attestation is only as accurate as inventory completeness. The VEX model depends on exhaustive, correct inventory mapping of build provenance. Gaps in SBOM coverage, undocumented custom images, or statically linked or embedded variants can evade vendor inventory and remain unobserved.
- Operational complexity for large fleets. Automating VEX ingestion helps for standard product families (for example, Azure Linux images), but organizations with broad, hybrid estates (on‑prem, cloud, custom images, WSL nodes, marketplace appliances) still need bespoke inspection and image-rebuild pipelines. That adds operational overhead during high-volume CVE waves.
How defenders should act now (concise action plan)
- Treat the MSRC Azure Linux attestation as an immediate remediation signal for all Azure Linux images and artifacts in your estate. Patch or replace images per Microsoft guidance.
- For every other Microsoft-supplied or Microsoft-distributed artifact in your estate (WSL kernels, Azure VM images, Marketplace images, container node images), perform artifact verification:
- Pull SBOMs or image manifests and search for the kernel package / commit ranges that OSV, NVD, and vendor trackers mapped to CVE-2025-38639.
- Check kernel configs for xt_nfacct presence, or inspect /lib/modules for matching modules.
- Where verification is non-trivial, apply temporary mitigations (isolate, limit local access, monitor kernel logs).
- Automate: subscribe to Microsoft’s CSAF/VEX feeds and your distro vendor advisories and integrate them into your vulnerability management pipeline so attested products are automatically triaged and remediated.
Conclusion
CVE-2025-38639 is a legitimate memory-safety defect in the Linux netfilter xt_nfacct code that multiple upstream and downstream maintainers have fixed and mapped into vendor advisories. Microsoft has
authoritatively attested that Azure Linux includes the implicated component and is therefore potentially affected; that attestation is an important and actionable signal for Azure Linux customers. However, that attestation is product-scoped — it does not, by itself, prove that other Microsoft products are free from the vulnerable code. Any Microsoft artifact that ships a kernel built from the vulnerable upstream range with the xt_nfacct functionality enabled could theoretically be affected until either Microsoft attests it as clean/not-affected or you verify the artifact directly. Treat Azure Linux as confirmed in-scope for remediation and treat every other Microsoft artifact as
unverified until you confirm otherwise using SBOMs, kernel configs, image scans, or Microsoft’s expanding VEX attestations.
Source: MSRC
Security Update Guide - Microsoft Security Response Center