Microsoft has confirmed that Azure Linux kernels are affected by CVE-2025-22025, a memory leak in the Linux NFS server that can be exploited to crash systems or degrade performance over time. The vulnerability, rated 5.5 on the CVSS scale, requires local access to trigger, but for anyone running NFS shares on Azure virtual machines or other Microsoft-provided Linux images, it demands immediate attention. Patches are already available from Microsoft and upstream distributions; here’s how to protect your environment.
What CVE-2025-22025 Is and How It Works
At its core, CVE-2025-22025 is a reference-counting error in the kernel code that handles NFS delegation recalls. When an NFS client holds a delegation—a temporary exclusive right to a file—the server can revoke it. The revocation process queues a callback to the client, and before queuing, the kernel increments a reference count on a dl_stid structure to prevent it from being freed prematurely. Normally, once the callback completes, a release function decrements the count.
The bug appears when the function nfsd4_run_cb() fails to queue the callback. In that failure path, the code never decrements the reference count it had just incremented. Over time, repeated failures leave nfs4_stid objects unreachable but still allocated, slowly starving the kernel of memory. In practical terms, an unprivileged local user or process that can repeatedly force delegation-recall failures—a scenario that can occur under specific load conditions or with crafted NFS operations—can cause the server to become unresponsive or crash.
Upstream kernel developers fixed the flaw with a simple defensive check: after the queue attempt, if it fails, release the reference immediately by calling nfs4_put_stid(). That patch has been backported to stable kernel branches and is included in the updated Azure Linux kernels that Microsoft is now pushing to customers.
- CVE ID: CVE-2025-22025
- Component: Linux kernel, NFS server (nfsd)
- Fix: Check return value of
nfsd4_run_cb()and callnfs4_put_stid()on failure - Upstream commit: Available from Linux stable and mainline trees; distribution vendors have incorporated backports
Who Is Affected — and What’s at Stake
Azure Linux Users: Confirmed Impact
The Microsoft Security Response Center (MSRC) has explicitly stated that “Azure Linux includes this open-source library and is therefore potentially affected.” In other words, the kernels Microsoft ships as part of its Azure Linux distribution contain the vulnerable code, and an attacker with local access can exploit the leak to impair NFS services. The practical impact is a denial-of-service condition: memory exhaustion leading to kernel panics, hangs, or forced reboots.
Because the vulnerability is local, it cannot be triggered remotely over the network by itself. However, in multi-tenant or shared environments—including container hosts where multiple users run code—the risk escalates. A compromised low-privileged process could weaponize the leak to disrupt a critical NFS server.
Other Microsoft-Supplied Linux Images: Treat as Unknown
Microsoft’s attestation only covers Azure Linux at this moment. That does not mean other Linux artifacts—WSL2 kernels, Marketplace virtual machine images, Azure-tuned Linux kernels for services—are immune. The company is still rolling out its VEX (Vulnerability Exploitability eXchange) attestations, which will eventually provide machine-readable status for every product. Until those statements are published, absence of an explicit “Known Affected” or “Not Affected” label should be treated as an unknown.
If you run any Linux image that Microsoft provides, regardless of its origin, you should independently verify whether the kernel contains the vulnerable NFS code path. This includes images you launch from the Azure Marketplace, custom WSL2 kernels, and even container base images that bundle a kernel.
What About Other Distributions?
This is a Linux kernel bug, not a Microsoft-specific one. Distribution advisories from Red Hat, Debian, Amazon Linux, and others show that any system running an unpatched kernel with NFS server support is potentially vulnerable. If you operate non-Azure Linux servers that export NFS shares, apply your distributor’s kernel updates without delay.
How We Got Here
CVE-2025-22025 was disclosed in April 2025 as part of the regular kernel security update cycle. The bug was present in the NFS server code for multiple kernel releases before the fix landed in mainline. The upstream linux-cve-announce mailing list distributed the advisory, and the National Vulnerability Database (NVD) assigned it a CVSS 3.1 score of 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Shortly afterward, enterprise distributions began incorporating the patch.
Microsoft’s MSRC entry appeared on the update guide soon after, confirming the Azure Linux impact. The phrasing Microsoft uses—“includes this open-source library and is therefore potentially affected”—is a product-scoped inventory statement. It tells administrators that the Azure Linux images they run from Microsoft do contain the vulnerable component. It is not a claim that the vulnerability is exclusive to Azure Linux, nor that other Microsoft products are automatically safe.
Microsoft has publicly committed to expanding its VEX attestations starting in October 2025, which would allow automated vulnerability management systems to ingest per-product status directly. For now, only Azure Linux has been explicitly called out. Other products may receive attestations as inventories are completed.
What to Do: Patch, Scan, and Mitigate
Immediate Priority: Patch Azure Linux Images
Microsoft has released updated kernel packages for Azure Linux. The steps to apply them depend on your package manager:
- For APT-based images (e.g., Azure Linux 2):
sudo apt update && sudo apt upgrade - For RPM-based images (e.g., Azure Linux 3):
sudo dnf check-update && sudo dnf upgrade
After updating, verify the running kernel version with uname -r. It should match the latest available from the repository. A reboot is typically required to load the new kernel; plan a maintenance window if needed.
If you use Azure’s automatic guest OS update features, confirm that your deployment is configured to receive and apply security updates promptly. Also check that your NFS service restarts correctly after the reboot and that no abnormal memory growth appears.
For Other Microsoft-Supplied Linux Artifacts: Inventory and Scan
Absent an official “Not Affected” statement, you must discover the status yourself.
- List every Linux kernel in your estate—WSL2 instances, Azure VM images, custom Marketplace solutions, and container base images. Note the exact kernel version and build metadata.
- Compare against known fixed versions. The upstream fix was introduced in development and backported to multiple stable series. Your distribution’s advisory will list the precise package versions that contain the fix. For example, a Red Hat advisory might list
kernel-4.18.0-553.13.1.el8_10as fixed. - Scan images for the vulnerable code path. If you can extract the kernel config, check that
CONFIG_NFSDis not set, but this is rarely practical in production. A more reliable approach is to examine the running kernel’s symbols or module list for nfsd components. If nfsd is loaded (lsmod | grep nfsd), the code is present. - Apply vendor updates for the affected image. For WSL2, you can download an updated kernel from Microsoft or rebuild from fixed sources. For Marketplace images, pull the latest published version or patch in place.
Compensation and Monitoring
If you cannot patch immediately, reduce exposure by limiting local access to the NFS server. Ensure only trusted users can run commands on the machine, and use SELinux or AppArmor to restrict process capabilities.
Monitor for the memory leak with kernel tools:
- Enable kmemleak if supported: write to /sys/kernel/debug/kmemleak and view the report.
- Check kernel logs for allocation failure messages or backtraces that match the nfs4_stid leak signature (the upstream traces show calls like nfsd4_process_open1 and nfsd4_open).
- Set alerts on memory usage for nodes running nfsd, and watch for sustained growth that does not correspond to normal workload.
Verification After Patching
Once patched, reproduce a normal NFS workload and observe memory consumption over several hours. Use slabtop or read from /proc/slabinfo to confirm that nfs4_stid structures are not accumulating. If your environment allows, forcibly trigger delegation recalls and ensure no objects are leaked.
Outlook: Keep an Eye on Expanding Attestations
Microsoft will extend its VEX attestations throughout 2025 and beyond. Watch the MSRC CVE page for CVE-2025-22025 for status changes—if other products, such as specific WSL2 kernel builds or certain Azure VM images, receive a “Known Affected” or “Fixed” label, act accordingly.
Other enterprise Linux distributors will continue to backport the fix into their long-term support kernels. If you run a custom or third-party kernel that might be based on an affected version, verify that the patch is included.
Finally, while no public proof-of-concept exploit has been observed, the nature of the bug (a simple reference-counting omission) makes it straightforward for a determined local attacker to craft a reliable trigger. Treat this vulnerability as a quiet but persistent availability risk, and close the window by patching without delay.