Microsoft’s short public attestation that “Azure Linux includes this open‑source library and is therefore potentially affected” is an authoritative, product‑level inventory statement — but it is not a proof that Azure Linux is the only Microsoft product that might carry the vulnerable Linux kernel code behind CVE‑2025‑38351. Read precisely, Microsoft has confirmed Azure Linux as a known carrier and committed to publishing machine‑readable CSAF/VEX attestations (the VEX pilot began in October 2025), and it will expand those attestations if additional Microsoft products are identified. In practice, defenders must treat Azure Linux as confirmed affected while immediately performing artifact‑level verification across all Microsoft‑distributed kernel artifacts in their estate.
CVE‑2025‑38351 is a Linux kernel vulnerability in the KVM paravirtualization path for x86 Hyper‑V hypercalls. At a high level, the flaw allows a guest to supply non‑canonical guest virtual addresses (GVAs) in paravirtual TLB‑flush hypercalls; the kernel code did not filter those invalid addresses before issuing CPU INVVPID/INVLPGA instructions. Because Intel’s INVVPID semantics explicitly fail on non‑canonical addresses while AMD’s INVLPGA silently ignores them, the observable behavior differs by CPU vendor. On Intel hosts this can result in failed invalidation operations, kernel warnings, and in some circumstances instability or denial‑of‑service conditions for the guest or host.
Microsoft’s public advisory language names Azure Linux (the Microsoft‑maintained Linux distribution formerly known as CBL‑Mariner) as a product that includes the implicated upstream code and therefore requires remediation. Microsoft also announced a phased rollout of machine‑readable VEX/CSAF attestations starting in October 2025 to make product‑level mappings consumable by automated vulnerability management pipelines.
That combination — an upstream Linux kernel fix plus a vendor product‑attestation — raises an operational question administrators frequently ask: “Does Microsoft’s wording mean Azure Linux is the only Microsoft product affected?” The short answer is no, not necessarily. The attestation is authoritative for Azure Linux, but it is intentionally phased and product‑scoped; other Microsoft artifacts that ship or embed Linux kernels may also include the same upstream code until they are individually inventoried and attested.
When a malformed (non‑canonical) GVA is handed to Intel’s INVVPID instruction it will raise an error or otherwise return failure; AMD’s INVLPGA, by contrast, treats non‑canonical addresses as a no‑op. Because the kernel did not filter non‑canonical entries before dispatching INVVPID/INVLPGA, unfiltered input could cause INVVPID failures on Intel hosts and inconsistent behavior across CPU families.
Why Microsoft did this:
Why the attestation is not exclusive:
However, the nuance matters: Microsoft’s attestation is product‑scoped and phased. It does not prove exclusivity. Other Microsoft artifacts that embed Linux kernels or paravirtualization components may still carry the same upstream code until they are individually verified and attested. Operators must therefore treat Azure Linux as a confirmed remediation priority while performing comprehensive, artifact‑level discovery, verification, and remediation across WSL kernels, Azure VM images, AKS nodes, Marketplace appliances, and any Microsoft‑distributed kernel artifacts they run.
Patch Azure Linux now, inventory and verify all Microsoft‑supplied kernel artifacts in your environment, ingest VEX/CSAF attestations as they arrive, and apply a layered mitigation approach — livepatch where possible, monitor for hypercall failures, and harden guest/hypervisor boundaries — to reduce blast radius while you close out the remaining verification tasks.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE‑2025‑38351 is a Linux kernel vulnerability in the KVM paravirtualization path for x86 Hyper‑V hypercalls. At a high level, the flaw allows a guest to supply non‑canonical guest virtual addresses (GVAs) in paravirtual TLB‑flush hypercalls; the kernel code did not filter those invalid addresses before issuing CPU INVVPID/INVLPGA instructions. Because Intel’s INVVPID semantics explicitly fail on non‑canonical addresses while AMD’s INVLPGA silently ignores them, the observable behavior differs by CPU vendor. On Intel hosts this can result in failed invalidation operations, kernel warnings, and in some circumstances instability or denial‑of‑service conditions for the guest or host.Microsoft’s public advisory language names Azure Linux (the Microsoft‑maintained Linux distribution formerly known as CBL‑Mariner) as a product that includes the implicated upstream code and therefore requires remediation. Microsoft also announced a phased rollout of machine‑readable VEX/CSAF attestations starting in October 2025 to make product‑level mappings consumable by automated vulnerability management pipelines.
That combination — an upstream Linux kernel fix plus a vendor product‑attestation — raises an operational question administrators frequently ask: “Does Microsoft’s wording mean Azure Linux is the only Microsoft product affected?” The short answer is no, not necessarily. The attestation is authoritative for Azure Linux, but it is intentionally phased and product‑scoped; other Microsoft artifacts that ship or embed Linux kernels may also include the same upstream code until they are individually inventoried and attested.
What the vulnerability actually is (technical summary)
How the PV TLB flush hypercalls work
KVM guests running on hypervisors may use paravirtualized hypercalls to request targeted operations from the host — one of these operations is a paravirtual TLB (Translation Lookaside Buffer) flush which tells the host to invalidate cached virtual-to-physical translations for specified guest virtual addresses. To accomplish this efficiently the hypercalls accept a list of GVAs to invalidate.The root cause
The vulnerable kernel path accepted a list of GVAs and forwarded them to the CPU invalidation instructions without proper canonical‑address validation. On x86‑64 architectures canonical addresses are those with the high address bits sign‑extended correctly; non‑canonical addresses are malformed and considered invalid by certain CPU instructions.When a malformed (non‑canonical) GVA is handed to Intel’s INVVPID instruction it will raise an error or otherwise return failure; AMD’s INVLPGA, by contrast, treats non‑canonical addresses as a no‑op. Because the kernel did not filter non‑canonical entries before dispatching INVVPID/INVLPGA, unfiltered input could cause INVVPID failures on Intel hosts and inconsistent behavior across CPU families.
Practical impact and exploitability
- Primary impact: availability — kernel warnings, hypervisor failures, or guest/host instability when particular sequences of paravirtual TLB flushes include non‑canonical addresses.
- Attack vector: requires code running in a guest (local to the VM) able to issue Hyper‑V style paravirtual hypercalls and to pass carefully crafted GVA lists. This is not a remote network attack against the host but is a local guest‑to‑host or guest‑to‑host‑service vector.
- Severity profile: medium‑to‑high for multi‑tenant environments where a malicious or compromised guest might intentionally attempt to destabilize the host or other co‑located guests; lower priority for single‑tenant, tightly‑controlled hosts where guest hypercall exposure is restricted.
Microsoft’s product attestation and the VEX/CSAF rollout
Microsoft’s published advisory language is deliberately concise: it confirms that Azure Linux includes the implicated upstream component and is therefore potentially affected. That statement is paired with Microsoft’s public commitment to publish machine‑readable VEX/CSAF attestations (the VEX pilot began in October 2025) and to update the CVE/VEX record if additional Microsoft products are discovered to include the same upstream code.Why Microsoft did this:
- Publishing VEX/CSAF attestation data lets customers automate product‑level triage: a VEX file can state whether a specific Microsoft product is Known Affected, Not Affected, Under Investigation, or Fixed relative to a CVE.
- Starting with Azure Linux is operationally sensible: it is a single, well‑scoped Linux distribution Microsoft maintains, making early inventory and mapping tractable.
- The rollout is phased; a lack of an attestation for another product does not indicate “not affected,” it indicates “not yet attested.”
- Improves automation and reduces false positives for enterprise scanners and SIEM/Vulnerability Management systems.
- Gives Azure Linux customers a clear action path.
- Increases transparency compared with opaque advisory prose.
- The attestation is product‑scoped and phased, not global. Microsoft has explicitly committed to updating the mapping if more products are found to include the code.
- Large vendors ship many distinct artifacts (WSL kernels, VM images, AKS node images, Marketplace appliances) with different kernel versions and build configs. Whether those artifacts include the vulnerable code is a per‑artifact fact.
Is Azure Linux the only Microsoft product that includes the library and is therefore potentially affected?
Short, precise answer: Microsoft has attested that Azure Linux includes the implicated upstream code and is potentially affected. That is authoritative for Azure Linux. However, Microsoft’s attestation does not prove that no other Microsoft product contains the vulnerable code. Other Microsoft‑distributed artifacts that embed Linux kernels or QEMU/KVM components — such as WSL2 kernels, Azure VM images, linux‑azure variants, AKS node images, Marketplace images, partner appliances, and specialized kernel builds — may include the same upstream components depending on kernel version, build configuration, and selective backports.Why the attestation is not exclusive:
- Kernel sources and userland libraries are reused across many artifacts; a vulnerability fixed in an upstream commit may have been backported differently across artifacts.
- Whether a given Microsoft artifact ships the vulnerable code depends on the exact upstream commit range, the kernel configuration flags chosen at build time (CONFIG_*), and whether Microsoft applied backports or different patching schedules.
- Microsoft’s phased VEX rollout intentionally starts with Azure Linux; absence of attestations for other products means “not yet attested,” not “not affected.”
Practical, prioritized action plan for defenders
Below is a pragmatic, prioritized checklist you can adopt immediately. Apply the steps in order: confirm Azure Linux remediation, then expand artifact discovery, verification, and remediation across the estate.- Prioritize Azure Linux images and hosts
- Apply Microsoft’s kernel updates for Azure Linux immediately.
- If you manage Azure Marketplace images or custom images built from Azure Linux, rebuild and redeploy with the fixed kernel.
- Inventory Microsoft‑distributed artifacts (high level)
- Identify all hosts, VMs, containers, and developer endpoints that run Microsoft‑distributed Linux artifacts:
- Azure Linux images
- WSL2 kernels on Windows clients
- linux‑azure or vendor kernels used by some Azure VM SKUs
- AKS node images and curated base images
- Azure Marketplace images and partner appliances
- Treat each of these as a distinct artifact that must be individually verified.
- Verify kernel presence and version (artifact‑level)
- Use the following checks on each Linux host or image:
- uname -r — identifies the running kernel version.
- cat /proc/version — kernel build info, may include vendor tags.
- grep CONFIG_HYPERV /boot/config-$(uname -r) or zgrep CONFIG_HYPERV /boot/config-$(uname -r) — checks for Hyper‑V paravirt support.
- For package‑managed systems:
- Debian/Ubuntu: apt policy linux-image-$(uname -r) or dpkg -l | grep linux-image
- RHEL/CentOS/Fedora: rpm -q kernel-core
- For WSL2:
- On Windows, run wsl --status to see the kernel version, and wsl --update to apply the Microsoft‑distributed WSL kernel update.
- If you maintain your own kernel builds, map your build’s upstream commit range to the upstream fix commit to confirm whether the fix exists in your artifact.
- Use SBOMs and VEX/CSAF where available
- Ingest Microsoft’s CSAF/VEX feeds for Azure Linux into your vulnerability management pipeline.
- Request SBOMs or VEX attestations from Microsoft or third‑party image publishers for Marketplace images or appliances you run.
- Remember: VEX attestation is authoritative for the artifact it names; unlisted artifacts remain unverified.
- Detection and monitoring
- Add monitoring for kernel oopses and unusual INVVPID/INVLPGA failures in host logs.
- Search dmesg and /var/log/messages for hypervisor‑paravirt warnings after remediation to ensure fixes do not introduce regressions.
- For multi‑tenant hypervisor hosts, increase scrutiny on guest hypercall usage patterns and abnormal TLB flush requests.
- Mitigations while patching
- Where practical, restrict guest usage of paravirtual hypercalls to trusted guests only.
- Consider temporary isolation of untrusted or new guests that may exercise hypercall interfaces aggressively.
- Where vendor livepatch/livekernel mechanisms exist, use them to reduce planned downtime; otherwise schedule rolling reboots after kernel upgrades.
- Communicate and document
- Record remediation status in SBOM/inventory systems and mark Azure Linux assets as remediated per Microsoft’s VEX attestation.
- Document per‑artifact verification results for WSL clients, Ubuntu/Debian derived images, AKS nodes, and Marketplace appliances.
How to verify whether a specific image contains the vulnerable code (practical checks)
The question is not hypothetical: whether a Microsoft image includes the vulnerable commit is a per‑artifact fact. Below are practical verification techniques you can use in automated scans or manual triage.- For running Linux hosts:
- Check kernel build and vendor tags:
- uname -v and cat /proc/version both provide build metadata; vendor kernels often include vendor or distro tags.
- Check kernel configuration for paravirtual support:
- Search /boot/config-* for CONFIG_HYPERV or paravirt options. If Hyper‑V paravirt options are disabled, the specific KVM hypercalls in question may not be reachable from guests.
- Map your kernel version to upstream stable branches and check whether the upstream fix commit is present in that release series.
- For WSL2 clients:
- On Windows: wsl --status (shows kernel version) and wsl --update (installs the latest Microsoft WSL kernel).
- If your organization distributes custom WSL kernels, treat those as self‑maintained artifacts: check the kernel version and rebuild with the upstream fix if necessary.
- For images and offline kernels:
- Extract the kernel image from the VM image or gather the packaged kernel package (rpm, deb).
- Inspect the kernel .config inside the package (often under /boot) to determine whether affected components are built.
- If you maintain a private image repository, include the kernel version and build metadata in image metadata so you can query it programmatically.
- For marketplaces and partner appliances:
- Request an SBOM and vendor attestation for each published image and validate the kernel package versions listed.
- If vendor attestations are not available, run the image in a sandbox and perform the checks above.
Threat model and risk analysis
Notable strengths (what Microsoft’s attestation and the upstream fixes deliver)
- Microsoft’s VEX/CSAF initiative makes it possible to automatically triage Microsoft products by vulnerability status, reducing noisy alerts and helping defenders prioritize.
- Vendor attestation for Azure Linux means Azure customers have a clear remediation path and can often rely on vendor patches and livepatches where available.
- The upstream kernel fix is targeted and surgical; it corrects the validation gap and reduces the surface for malformed hypercall inputs.
Potential risks and weaknesses
- False sense of exclusivity: operators who read Microsoft’s single‑line attestation as “only Azure Linux” risk leaving other Microsoft‑supplied artifacts unverified and vulnerable.
- Large artifact surface: Microsoft — like other large vendors — ships many distinct artifacts built from different kernel trees. Each is a separate verification job.
- Timing and rollout gaps: VEX/CSAF rollout is phased. Until VEX attests a given product, defenders cannot rely on Microsoft’s attestation and must verify artifacts themselves.
- Cross‑vendor behavior differences: Intel vs AMD behavior means exploitability and observability differ by host CPU vendor; defenders must test across their hardware matrix.
- Multi‑tenant cloud risk: in multi‑tenant environments a malicious guest could intentionally attempt to trigger the flaw to affect host stability or other guests. This is why host hardening, isolation, and careful hypercall exposure are important.
Mitigations beyond patching
While patching affected kernels is the primary remedy, defenders should take additional steps to reduce risk and detect exploitation attempts.- Harden guest privileges:
- Limit guest capabilities and remove any unnecessary paravirtualization interfaces if possible.
- Use stricter image hardening and only run trusted guest images on hosts that could be targeted.
- Hypervisor hardening:
- Apply hypervisor updates and ensure hypervisor code that mediates guest hypercalls includes robust input validation.
- Where possible, instrument hypervisor paths to detect unusual hypercall argument patterns.
- Monitoring and EDR rules:
- Add log detection for kernel warnings and INVVPID failures. Correlate these with guest identification to quickly quarantine suspicious VMs.
- For cloud platforms, implement automated policies that isolate or throttle guests that produce repeated hypercall errors.
- Operational controls:
- Implement incident playbooks for host instability: automated snapshotting, host quarantine, and planned host reboots.
- Use rolling maintenance windows and livepatching to minimize impact while remediating large fleets.
How to communicate this to stakeholders
Security leaders and system owners need clear, actionable language. Use the following guidance to brief peers or management:- Message to executives: “Microsoft has confirmed Azure Linux as a product that includes kernel code vulnerable to CVE‑2025‑38351. We have prioritized those Azure Linux images and hosts for immediate patching. Other Microsoft‑distributed kernels (WSL2, Marketplace images, AKS nodes) are unverified and will be inventoried and validated in the next 48–72 hours.”
- Message to engineering teams: “If you produce or consume Microsoft‑distributed images, run the artifact verification script in our central pipeline. For WSL2 users, push the WSL kernel update through corporate update tooling.”
- Message to operations: “Patch Azure Linux hosts now; after that, follow the artifact‑inventory checklist and schedule kernel updates or image rebuilds for each verified affected artifact. Monitor for kernel oopses and INVVPID/INVLPGA warnings.”
Conclusion
Microsoft’s statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is an important and welcome transparency signal: it names a specific product (Azure Linux) Microsoft has inventory‑checked and flagged for remediation, and Microsoft has committed to publishing VEX/CSAF attestations to make such mappings machine‑readable. That clarity is valuable for automation and prioritization.However, the nuance matters: Microsoft’s attestation is product‑scoped and phased. It does not prove exclusivity. Other Microsoft artifacts that embed Linux kernels or paravirtualization components may still carry the same upstream code until they are individually verified and attested. Operators must therefore treat Azure Linux as a confirmed remediation priority while performing comprehensive, artifact‑level discovery, verification, and remediation across WSL kernels, Azure VM images, AKS nodes, Marketplace appliances, and any Microsoft‑distributed kernel artifacts they run.
Patch Azure Linux now, inventory and verify all Microsoft‑supplied kernel artifacts in your environment, ingest VEX/CSAF attestations as they arrive, and apply a layered mitigation approach — livepatch where possible, monitor for hypercall failures, and harden guest/hypervisor boundaries — to reduce blast radius while you close out the remaining verification tasks.
Source: MSRC Security Update Guide - Microsoft Security Response Center
