CVE-2025-37988: Azure Linux Attestation and Exposure Guide

Microsoft’s advisory around CVE‑2025‑37988 makes an important distinction: the Azure Linux distribution (formerly CBL‑Mariner) is the only Microsoft product that the company has publicly attested contains the vulnerable upstream kernel code — but that admission is a statement about completed inventory and disclosure, not an exhaustive proof that no other Microsoft product or artifact could include the same upstream code and therefore be potentially affected. This article unpacks the vulnerability, the upstream fixes, what Microsoft’s attestation does — and does not — mean, and the practical steps administrators should take to determine exposure across Microsoft-supplied Linux artifacts (Azure VM images, WSL2 kernels, AKS node images, Marketplace appliances and more).

Background / Overview​

CVE‑2025‑37988 is a race‑condition fix in the Linux kernel addressing a pair of timing races in the MNT_TREE_BENEATH handling inside do_move_mount(). The bug arises from complex interactions between mountpoint pinning, mount namespace locking (namespace_sem), mount_lock, and inode locking. In short, code that attempts to lock a mountpoint for operations beneath a given path could be tricked into operating on a mountpoint whose parent chain (->mnt_parent) changes under it, allowing dangerous races between mounts, move operations, and unmounts. The upstream kernel project released fixes that rearrange locking and reference/pinning behavior to ensure a stable mount/dentry pair is grabbed before inode_lock() is used.
Several independent sources — upstream kernel commits and mainstream distribution security advisories — describe the defect and list the commit(s) that fix it. Distribution advisories (and downstream vendor packages) are the practical delivery vehicle for the patch to millions of systems. Microsoft’s public advisory language for this CVE explicitly confirms Azure Linux as an attested product that includes the affected component, and Microsoft points to its new CSAF/VEX attestation program as the mechanism it will use to publish such inventory and exploitability information.

---

What the bug is — technical explanation​

The core of the race​

The vulnerability centers on how do_move_mount() and its helper do_lock_mount() manage locks and references for mountpoints — especially when the operation is specified as "beneath" a path (i.e., operating on mountpoints under a target path rather than just the target path itself).

• The kernel uses several synchronization primitives that influence mountpoint stability:
  • mount_lock — used to stabilize a mount’s ->mnt_parent.
  • namespace_sem — the namespace semaphore, which can also stabilize ->mnt_parent for mounted mounts.
  • inode_lock() — inode-level locking that nests around namespace_sem in certain codepaths.
• The vulnerable window occurs because the code pins a dentry (directory entry) but not always the matching mount at the same time. If ->mnt_parent or the mountpoint mapping can change between the moment the dentry is pinned and the moment the code acquires the locks it needs, concurrent mount --move or unmount operations can race and either remove references to the mount or change what the dentry points to.
• The practical consequence: code may proceed with operations assuming a mountpoint remains valid while it can be concurrently detached or shut down, potentially leaving the kernel holding references into a filesystem that is being torn down — with results ranging from corruption to crashes or denial of service.

Why the fix matters​

Upstream fixes change the locking order and pin both the dentry and its corresponding mount together before entering the critical region protected by inode_lock()/namespace_sem. That prevents the race described above by ensuring the relevant mount and dentry pair are pinned and stable for the duration of the critical sequence. In other words, the patch hardens the “time-of-check / time-of-use” window for mount operations.

---

Severity and exploitability — what attackers can and cannot do​

• CVE‑2025‑37988 is a local race condition. The kernel race is not remotely exploitable without local code execution or at least local unprivileged access to perform mount operations or namespace manipulations.
• Public vulnerability databases and vendor advisories that summarized the upstream fix characterize the issue as a medium‑impact race condition: it can cause memory corruption, file system instability, or denial of service if exploited locally, but it does not constitute a straightforward remote privilege escalation vector in its unpatched, vanilla description.
• Practical exploitation depends on the environment. Systems that enable unprivileged user namespaces, containers (where untrusted code may have limited capability to influence mounts), or multi‑tenant hosts with constrained isolation could present better opportunities for an attacker to leverage the race.

---

Which kernel versions and releases were affected​

Upstream commit notes and distribution advisories indicate that the problem was introduced/observed in recent mainline kernels in the 6.x series and fixed via a set of stable patches. Vendor advisories map those commits to the patched package versions they ship. Because distributions and vendors backport fixes, the exact “vulnerable” package list varies:

• Upstream descriptions cite fixes whose commit ranges correspond to several recent 6.x kernel ranges. Distributions such as Ubuntu reflected the patch in their kernel packages; other distros likewise published updates.
• Importantly: exact affected/ fixed versions differ by distribution because vendors may backport the patch into older kernel branches or rebuild kernels with different configuration options.

Operational takeaway: identify the kernel version (and vendor package release) on each host and compare it to vendor advisories for whether the kernel package includes the upstream fix. Do not rely solely on the mainline version number without confirming the vendor’s package changelog.

---

What Microsoft said — reading the advisory language​

Microsoft’s published update for the CVE makes two key claims that are often conflated:

1. Microsoft stated that Azure Linux is the product they have attested to include the implicated open‑source component and therefore is confirmed as affected (unless patched).
2. Microsoft also said that their commitment to transparency — in the form of CSAF/VEX attestations — means they will expand attestations beyond Azure Linux and update the CVE if additional Microsoft products are identified as impacted.

Those two sentences read together accurately describe Microsoft’s disclosure posture: Azure Linux is a confirmed inclusion, and Microsoft’s new VEX/CSAF program is the channel they will use to publish similar attestations for other Microsoft products as that inventory work completes. However, those sentences should not be read as a definitive technical guarantee that no other Microsoft product could contain the same upstream component. In short: attested does not equal exclusive.

---

Is Azure Linux the only Microsoft product that includes the vulnerable code?​

Short answer: No — Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) as containing the vulnerable upstream code for this CVE. That attestation is important and useful — it’s a confirmed hit for that product — but it is a statement about Microsoft’s completed inventory work, not a global proof that other Microsoft artifacts do not include the same code.
Here’s why the distinction matters and why security teams should not stop with that single attestation:

• Microsoft maintains multiple Linux‑related artifacts and builds that are produced separately:
  • The Azure Linux distribution images and packages.
  • The WSL2 kernel repository and WSL2 kernel binaries shipped to Windows clients (and sometimes surfaced as binary blobs or source on public repos).
  • Azure VM image kernels and Marketplace VM images that may contain vendor-supplied or Microsoft-curated kernel builds.
  • AKS node images, appliance images in the Marketplace, and kernel packages used by Azure services.
• The WSL2 kernel source tree and other Microsoft kernel artifacts have historically included many of the same upstream subsystems (the kernel proper, filesystem and driver trees). Whether a particular build contains the vulnerable code depends on the kernel version and whether the specific commits were present. The presence of the same upstream file path or subsystem in a Microsoft kernel artifact is sufficient to require inventory checking; it does not automatically imply vulnerability, because vendor and product kernels differ by version and applied fixes.
• Microsoft’s VEX/CSAF rollout deliberately started with Azure Linux to validate tooling and processes. Absence of an attestation for a product is therefore not the same as a statement the product is unaffected — it sometimes simply means Microsoft has not yet published the machine‑readable attestation for that SKU.

Therefore, by Microsoft’s own wording and by practical supply‑chain realities, other Microsoft products could include the same upstream code and therefore may be potentially affected — but only a product-level inventory check or published attestation can confirm inclusion and exposure.

---

Practical inventory — where to look in the Microsoft ecosystem​

If you are responsible for a Microsoft-hosted or Microsoft-supplied Linux artifact, here’s a prioritized checklist:

1. Azure Linux (attested): Confirm whether your Azure Linux instances have applied the vendor kernel update that includes the upstream fix. This is the SKU Microsoft explicitly named.
2. WSL2 kernels: Check the WSL2 kernel binary version on Windows hosts and the WSL2 kernel source tree used to build those binaries. WSL2 kernels are built separately; if the WSL2 kernel in use contains an affected kernel version without the upstream fix, local exploitation scenarios (on a Windows host where an untrusted user has WSL access) could be possible.
3. Azure VM images and Marketplace appliances: Inventory the kernel package version included in Marketplace images you deploy. Marketplace images (and any Microsoft-curated images) may include vendor kernel builds that need to be compared to the upstream fix.
4. AKS nodes and curated images: Container host nodes often run vendor-supplied kernels. If you run AKS node pools using Microsoft-provided images or a curated image with a vulnerable kernel, treat those nodes as potential exposure.
5. Any Microsoft distribution artifacts you receive: If a Microsoft product bundles or distributes a Linux kernel or related kernel module, check the package version against vendor advisories.

For each artifact, the checklist is the same: identify the kernel (or package) version, consult vendor advisory changelogs or the vendor’s published VEX/CSAF attestation, and apply the vendor patch where indicated.

---

Detection and mitigation guidance​

Immediate mitigations​

• Apply the vendor patches. This is the preferred, straightforward mitigation: update the kernel package to the vendor-supplied release that contains the upstream fix.
• If patching is temporarily impossible, restrict access to local mount operations:
  • Disable or limit unprivileged user namespaces where feasible; many race or mount-based privilege escalation techniques rely on namespace features.
  • Harden container runtimes and host isolation. Avoid running untrusted code in environments where it can manipulate mounts or mount namespaces without strict containment.
• Consider kernel hardening modules (e.g., LKRG — Linux Kernel Runtime Guard) to detect and limit suspicious kernel behavior as an interim measure. These measures have limitations and can affect stability; test before deploying to production.

Monitoring guidance​

• Instrument kernel crash and OOM logging. The race can lead to filesystem shutdowns or crashes, so monitor for unusual kernel oops, panic or filesystem unmount logs.
• Look for unusual mount/unmount/move activity in your audit logs. Rapid or repeated mount --move / umount sequences from untrusted users could indicate an attempt to trigger the race.
• For WSL2 environments, monitor for unexpected WSL installations or unprivileged users creating namespaces or mounts.

Patch management best practices​

1. Prioritize hosts where untrusted or multi‑tenant code runs.
2. Use staged rollouts with canary hosts to reduce risk of regressions from kernel updates.
3. For managed clouds, follow provider advisories (e.g., Azure advisories and their CSRF/VEX attestation feed) and cross‑check with distribution advisories.

---

Why Microsoft’s VEX/CSAF program matters — and what it does not replace​

Microsoft’s move to publish CSAF (Common Security Advisory Framework) and machine‑readable VEX (Vulnerability Exploitability eXchange) attestations is a meaningful transparency step. VEX files explicitly state whether a given CVE affects a specific product, sub‑component, or configuration. For large enterprises consuming many Microsoft SKUs, VEX can simplify decision-making: it tells you if a CVE is relevant to a product you consume.
However, the VEX/CSAF rollout has caveats:

• It’s product-scoped and phased. Microsoft intentionally began with Azure Linux; rollouts to other SKUs are planned but incremental.
• VEX attestation for a product is authoritative for that product only. If you run several Microsoft artifacts (e.g., Azure Linux images, WSL2 kernels, Marketplace VM images), a VEX file for Azure Linux does not automatically cover the others.
• Absence of an attestation does not mean “not affected”; it may mean inventory work is ongoing.

Security teams should therefore use VEX/CSAF attestation as a strong signal — not as the only signal — and complement it with local inventory and vendor package checks.

---

A realistic timeline and what to expect​

• Upstream discovery/patch: the kernel project recorded the issue and landed fixes in the stable tree.
• Distribution updates: major distributions (Ubuntu, Debian, Red Hat) pushed kernel package updates; each vendor’s advisory maps to their package names and patch levels.
• Microsoft public attestation: Microsoft published an attestation for Azure Linux and reiterated that VEX/CSAF is the mechanism for further attestation work.
• What organizations should do now: inventory, prioritize, patch, and monitor. Expect Microsoft to publish additional attestations for other Microsoft products over time — but do not wait for those attestations to confirm exposure where you can verify it locally.

---

Risk analysis — strengths and remaining risks​

Strengths​

• The upstream fixes address the root cause by closing the time-of-check / time-of-use window through corrected locking and pinning semantics. That is a robust, systemic fix rather than a superficial workaround.
• Distributions and vendors have been quick to roll patches into kernel packages; public advisories reflect a coordinated response.
• Microsoft’s VEX/CSAF program increases transparency by explicitly tying CVEs to Microsoft SKUs and stating exploitability conditions where appropriate.

Risks and caveats​

• Inventory gaps remain across complex supply chains. Even within a single vendor’s ecosystem, multiple independently built kernel artifacts can exist; an attestation for one does not automatically confirm the state of others.
• Local exploitation risk is real in environments where untrusted code can influence mount namespaces. Cloud tenants, shared hosting environments, or systems allowing unprivileged namespace manipulation are higher risk.
• Detection is nontrivial. Race conditions often leave subtle traces (crashes, panics) rather than clear signs of exploitation; without aggressive monitoring, a successful exploit may show up only as an unexplained outage.
• Vendor backports complicate version‑based detection. A kernel package with a nominally older version number may already include the upstream fix; conversely, a newer version without the backport may still be vulnerable until patched. Rely on vendor changelogs and advisories rather than version numbers alone.

---

Concrete next steps for administrators​

1. Inventory your estate:
   • Identify hosts running Azure Linux, WSL2 kernels, Azure Marketplace images, and any Microsoft‑supplied Linux artifacts.
   • For each host, record the exact kernel package version and vendor package name.
2. Consult vendor advisories:
   • Check your distribution vendor’s security advisory for CVE‑2025‑37988 to determine whether the kernel package you run includes the upstream fix.
   • For Microsoft artifacts, consult the vendor‑published CSAF/VEX attestation (where available) and product advisories.
3. Patch with priority:
   • Prioritize patching hosts that host untrusted workloads, multi‑tenant environments, or run containerized workloads that could be manipulated by tenants.
4. Apply compensating controls where immediate patching is not possible:
   • Tighten namespace restrictions, reduce privilege to mount operations where practical, and harden container runtimes.
   • Implement monitoring for kernel panics, unusual mount activity and sudden filesystem shutdowns.
5. Track Microsoft attestations:
   • Use Microsoft’s VEX/CSAF feed for authoritative product-level status as it becomes available, but treat it as one input among many.
6. Test updates in canaries:
   • Roll kernel updates to a canary cohort, watch for regressions, then proceed with a staged rollout.

---

Final analysis and takeaway​

The heart of the matter is a familiar security supply‑chain truth: product attestations are powerful and helpful, but they are scoped and incremental. Microsoft’s explicit attestation that Azure Linux includes the upstream component implicated by CVE‑2025‑37988 is an important, concrete data point that tells customers where to start. It does not, however, mean Azure Linux is the only Microsoft product that could possibly be affected.
Security teams should treat the MSRC attestation as authoritative for Azure Linux and as a signal that Microsoft is now publishing machine‑readable attestations for open source components. At the same time, teams should perform their own inventory across all Microsoft-supplied kernel artifacts they consume (WSL2 kernels, Azure images, Marketplace appliances, AKS node images), check vendor changelogs and package release notes for the upstream fix, and patch or mitigate accordingly.
The good news: the upstream fix targets the root cause (locking/pinning semantics), and mainstream distributions already shipped patches. The remaining work is operational: inventory, patch management, and monitoring. The era of machine‑readable attestations (CSAF/VEX) will make this work easier over time — but for now, customers must combine vendor attestations with their own artifact checks to ensure there are no blind spots in their environments.
Apply the patch where it is available, validate kernels in use across all Microsoft-supplied artifacts, and treat Microsoft’s VEX/CSAF attestation as a valuable tool — but not as a substitute for practical inventory and patching discipline.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center