Microsoft’s one-line MSRC attestation that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate as far as it goes — but it is a product‑scoped inventory statement, not a technical guarantee that no other Microsoft product or internal image can contain the same vulnerable NFS server code; defenders must therefore treat Azure Linux as in-scope while also performing independent artifact-level discovery across other Microsoft-supplied kernels and images.
CVE-2025-22025 is a Linux-kernel vulnerability disclosed in April 2025 that affects the NFS server (nfsd) code path. In short, a reference-counting error can leave nfs4_stid structures unreferenced when a delegation-recall callback fails to queue; repeated triggering can produce a memory leak that, over time, may cause availability problems for servers running a vulnerable kernel. The issue description and the fix are documented in upstream kernel advisories and distribution security advisories.
The Microsoft Security Response Center (MSRC) entry for the CVE uses a concise FAQ-line that has become common across many Linux kernel CVE pages: “Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability? … Azure Linux includes this open-source library and is therefore potentially affected.” That phrasing is a mapping of Microsoft’s current inventory for the CVE, and Microsoft has publicly committed to extendinF/VEX attestations starting in October 2025 so customers can see which Microsoft artifacts are Known Affected, Not Affected, Under Investigation or Fixed.
This article explains what the MSRC statement does — and does not — mean, verifies the technical facts about CVE‑2025‑22025 against upstream and distro sources, and provides practical guidance and remediation steps for administrators who run Azure Linux images or other Microsoft-distributed kernels in their environments.
That means:
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE-2025-22025 is a Linux-kernel vulnerability disclosed in April 2025 that affects the NFS server (nfsd) code path. In short, a reference-counting error can leave nfs4_stid structures unreferenced when a delegation-recall callback fails to queue; repeated triggering can produce a memory leak that, over time, may cause availability problems for servers running a vulnerable kernel. The issue description and the fix are documented in upstream kernel advisories and distribution security advisories.The Microsoft Security Response Center (MSRC) entry for the CVE uses a concise FAQ-line that has become common across many Linux kernel CVE pages: “Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability? … Azure Linux includes this open-source library and is therefore potentially affected.” That phrasing is a mapping of Microsoft’s current inventory for the CVE, and Microsoft has publicly committed to extendinF/VEX attestations starting in October 2025 so customers can see which Microsoft artifacts are Known Affected, Not Affected, Under Investigation or Fixed.
This article explains what the MSRC statement does — and does not — mean, verifies the technical facts about CVE‑2025‑22025 against upstream and distro sources, and provides practical guidance and remediation steps for administrators who run Azure Linux images or other Microsoft-distributed kernels in their environments.
What the vulnerability actually is (technical summary)
The bug, in plain terms
- The defect lives in the NFS server (nfsd) code that handles delegation recall work.
- Before queuing a delegation-recall callback (nfsd4_run_cb), the code increments the reference count on a dl_stid (the NFS4 delegation stateid).
- If the call to nfsd4_run_cb fails, the previously incremented reference is not decremented, producing a leak of nfs4_stid objects that remain allocated and unreferenced.
- Over time, repeated failed queue attempts can cause the kernel to accumulate leaked objects and exhaust memory, creating an availability (denial-of-service) risk.
Severity and exploitability
- Multiple trackers and distribution advisories record CVSS v3.1 base score 5.5 for this issue, with an attack vector of Local (AV:L) and impact confined to Availability (A:H) rather than Confidentiality or Integrity. That is, an attacker needs local access (unprivileged user) to repeatedly trigger the leak; there is no indicated remote exploitation vector.
Fix
- The upstream fix is straightforward and defensive: check the return value from nfsd4_run_cb and call nfs4_put_stid if queuing the work failed, ensuring the reference-count increment is undone on failure.
- The patch was merged into upstream stable trees and subsequently packaged by major distributions and maintained-kernel vendors. Distribution advisories (Debian, Amazon Linux, Red Hat) and kernel-stable commits confirm the change and list fixed kernel versions or backports.
Is Azure Linux the only Microsoft product that includes the library and could be affected?
Short answer: No — but with an important qualifier.What Microsoft’s attestation actually declares
When MSRC states “Azure Linux includes this open‑source library and is therefore potentially affected,” it is accurately reporting the result of the product-level inventory Microsoft comhat statement declares Microsoft has confirmed the Azure Linux distribution (the kernel packages and/or images Microsoft builds and publishes under the Azure Linux family) contains the upstream kernel code mapped to the CVE and is therefore in-scope for remediation and VEX status classification. Microsoft has also committed publicly to expanding VEX/CSAF attestations and updating CVE pages if additional Microsoft products are found to ship the implicated code.Why that is not the same as “exclusive”
The presence of a kernel source file in an upstream repository is an artifact- and build‑specific property. Microsoft publishes hundreds of kernel images and related artifacts (Azure VM images, Marketplace images, WSL2 kernels, container base images, bespoke kernel builds used by platform services). Whether any specific Microsoft product includes the vulnerable code depends on the exact kernel version, configuration, and which commits were included when the kernel was built.That means:
- Azure Linux is the product Microsoft has publicly confirmed contains the implicated upstream component for this CVE.
- Absence of a Microsoft attestation for another product is not proof that product is free of the vulnerable code. It is simply an absence of public attestation; the artifact may or may not include the code depending on kernel version and build choices. Security teams must therefore perform discovery for other artifacts they run.
Verifying the claim: cross‑checking upstream and vendor sources
To be confident in the technical claims and the Microsoft product mapping, we cross‑checked multiple independent sources.- National Vulnerability Database (NVD): the CVE description and scoring, plus the technical summary of the nfsd dl_stid leak, are recorded by NVD. This establishes the public CVE metadata and CVSS scoring used by many downstream systems.
- Red Hat Bugzilla / Vendor trackers: Red Hat’s bug entry imports the OSIDB/CVE announcement and quotes the upstream advisory and stack traces showing unreferenced objects; it also links to the upstream linux-cve-announce post that explains the fix. Red Hat’s tracker documents the same root cause and the upstream remediation. (bugzilla.redhat.com)
- Distribution advisories (example: Amazon Linux ALAS): distribution security advisories list the CVE and the kernel packages that were updated or backported, providing concrete package-level remediation guidance for operators.
- Aggregated CVE trackers (OpenCVE / cvefeed / cvedetails): these sites list the affected kernel ranges, link to upstream patches, and summarize the remediation. They are secondary confirmations that the upstream fix was merged and packaged.
Practical implications for Microsoft customers and administrators
For Azure Linux customers
- Treat Microsoft’s MSRC attestation as authoritative for Azure Linux images: the product is in-scope and Microsoft will publish updates and VEX/CSAF attestations with status. Apply Microsoft-supplied kernel updates for Azure Linux as soon as they are available and tested in your environment.
For customers running other Microsoft-supplied artifacts (WSL, Marketplace images, Azure VM images, platform kernels)
- Do not assume “not mentioned” equals “not affected.” Absence of a VEX attestation or an explicit “Not Affected” classification should be treated as unknown until verified.
- Undertake artifact-level discovery:
- Inventory kernel versions and vendor-supplied images you run (WSL2 kernels, linux-azure kernels, Marketplace VM images, custom images).
- Inspect kernel version strings and build metadata. If possible, extract package metadata or SBOMs from the image.
- Scan images and containers for the vulnerable kernel package version ranges and for symbols/modules that indicate the NFS server code is present.
- Apply vendor-provided security updates or rebuild images with patched kernels if necessary.
- For VMs and images you control, check uname -r and package kernel metadata to map to the upstream fixed versions listed by NVD and distribution advisories.
- For container images or Marketplace images you do not control, treat them like black boxes: retrieve the image, run a container shell and inspect kernel artifacts or consult vendor SBOMs if provided.
- For WSL2, Microsoft’s published WSL kernel repository and release notes can be inspected to determine whether a particular release contains the vulnerable commit range; if you run custom WSL kernels, rebuild from fixed sources.
For defenders: prioritize by exposure
- If you run NFS servers on Azure Linux images, patch them quickly — CVE‑2025‑22025’s primary risk is availability through memory leak accumulation.
- Systems that do not run nfsd (for example Linux images used exclusively as clients, or Windows hosts without supplied Linux kernels) have no direct exposure from this specific code path.
- Where you cannot patch immediately, mitigate by reducing exposure and monitoring: limit locathat could repeatedly trigger the leak, monitor kernel memory and kmem leak reports, and set alerts for abnormal memory growth on nodes running nfsd.
How to interpret vendor attestations (CSAF/VEX) in practice
Microsoft’s CSAF/VEX rollout aims to give customers machine-readable attestations that can be automated into vulnerability management systems. VEX documents provide per‑product status: Known Affected, Not Affected, Under Investigation or Fixed. But some practical considerations remain:- VEX is only as useful as the inventory completeness behind it. Microsoft’s initial rollout began with Azure Linux artifacts; Microsoft has explicitly said it will update attestations as more artifact inventories are completed. That means a VEX document that names Azure Linux only reflects what Microsoft has finished mapping so far, not a claim that other products are impossible carriers.
- Organizations that operate hybrid fleets or that run Microsoft-published images from multiple sources must not substitute the vendor’s VEX attestations for local artifact scanning. VEX should be combined with SBOMs and runtime inspection to close gaps. Tools that consume VEX (SIEMs, patch management, orchestration systems) should still correlate artifact metadata (image digest, kernel version) with the attestation to reach a firm remediation decision.
- In short: treat MSRC/VEX as an authoritative, high-value signal for the artifacts it covers; use local discovery and SBOMs to verify the status of other artifacts.
Risk analysis — strengths and potential weak points in relying on the MSRC message
Strengths
- Microsoft’s attestation is clear and actionable for the product it names (Azure Linux). Customers with that product can immediately prioritize patching.
- The move to publish machine-readable VEX/CSAF attestations improves automation and reduces noisy alerts for customers who rely on Microsoft-supplied images. The blogpost announcing Microsoft’s VEX rollout explains the intended benefits and the machine-readable statuses.
Potential risks and limitations
- Inventory completeness: Microsoft’s public mapping only proves Microsoft’s internal inventory work for the named artifact; it does not and cannot, by itself, guarantee absence in other artifacts until those artifacts are also inventoried and attested. Absence of an attestation is not evidence of absence.
- Build‑time differences: even when two Microsoft products are both “Linux,” they may rely on different kernel trees, build options, or backports — meaning one product may be marked affected while another that includes a different kernel build is not. Customers must therefore verify artifact-level kernel versions and commit ranges.
- Timing / rollout: VEX/CSAF rollout is phased. Customers that rely on immediate global assurance for all Microsoft images should not assume completeness; they must continue artifact scanning until Microsoft’s attestations cover the artifacts they run.
Recommended checklist for operators (actionable steps)
- For Azure Linux images (highest priority)
- Identify affected Azure Linux images and nodes in your estate.
- Apply Microsoft-supplied kernel updates or image updates as published.
- Reboot nodes where required and validate that nfsd is functioning and memory use is normal.
- For other Microsoft-provided Linux artifacts (WSL, linux-azure, Marketplace images)
- Inventory image/kernel versions and build metadata.
- If you cannot determine status from vendor attestations, treat as Unknown and perform scanning.
- If vulnerable kernel ranges are present, apply vendor updates, rebuild images with fixed kernels, or replace images.
- For on-prem and hybrid systems
- Identify nodes running nfsd or that are NFS servers.
- Patch kernels according to your distribution’s advisory (Debian, Red Hat, Amazon Linux, etc.) or apply upstream stable patches if you maintain custom kernels.
- Monitoring, compensating controls, and validation
- Enable kernel memory leak monitoring and kmem checkers where feasible.
- Monitor for repeated failed nfsd delegation recall attempts in logs; correlate with memory growth.
- After patching, validate by reproducing normal workload and verifying no abnormal memory growth.
- Documentation and governance
- Record the CVE, the affected artifacts, and the mitigation steps in your vulnerability management system.
- Subscribe to MSRC VEX/CSAF feeds and distribution advisories so you receive updates if Microsoft expands its attestations.
What to watch for next (signals and indicators)
- Microsoft VEX/CSAF updates: Microsoft has committed to updating CVE pages and will publish attestations as inventories expand. Watch for status changes on the MSRC CVE entry and in the VEX feed for new “Known Affected” or “Fixed” flags for other Microsoft products.
- Distribution backports: many organizations run long-lived kernels with backported fixes. Confirm whether your distro’s kernel package includes the upstream fix rather than just relying on kernel version numbers. Distribution advisories (Debian LTS, Amazon Linux ALAS, Red Hat) typically list fixed package versions and backport details.
- Runtime telemetry: watch for repeated nfsd errors and unreferenced object traces in kernel logs — these are the exact symptoms the upstream tracebacks show when the leak occurs. Red Hat’s bug entry and upstream kernel stack traces provide the diagnostic signatures. (bugzilla.redhat.com)
Final assessment and guidance
- The MSRC statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate and actionable for customers running Azure Linux images. Operators should patch those images promptly and rely on Microsoft VEX/CSAF attestations for automation where available.
- However, Azure Linux is not necessarily the only Microsoft product that could include the vulnerable code: other Microsoft-provided Linux kernels, WSL kernels, Marketplace images, or platform artifacts may also carry the same upstream file depending on build choices and kernel versions. Absence of public attestation for those artifacts is not proof of non‑inclusion. Customers must therefore perform artifact-level discovery (SBOMs, image inspection, kernel version checks) and apply vendor or distribution patches as required.
- From a security operations perspective, treat MSRC’s Azure Linux attestation as a high-confidence, high-priority action item: patch Azure Linux images. For all other Microsoft artifacts, follow the checklist above to move from unknown to known status: inventory, scan, patch or rebuild, and validate.
Conclusion
CVE‑2025‑22025 is a real, pragmatic availability risk in the Linux kernel’s NFS server: a reference-counting bug that can leak kernel stateids when a delegation-recall callback fails to queue. Upstream fixes exist and distributions have issued backports or packages to remediate the issue. Microsoft’s MSRC entry truthfully reports that Azure Linux includes the implicated component and is therefore potentially affected — and Microsoft is rolling out machine-readable VEX attestations to make that signal automatable. But that MSRC line must be read as a product-scoped inventory result, not as a universal claim that the vulnerable code cannot appear in other Microsoft artifacts. Defenders should patch Azure Linux immediately and then perform artifact-level discovery and remediation across any other Microsoft-provided kernels or images in their environment until those artifacts are explicitly attested or verified as Not Affected.Source: MSRC Security Update Guide - Microsoft Security Response Center
