Microsoft’s concise MSRC wording — “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability” — is an authoritative, product‑level attestation for Azure Linux, but it is not a technical guarantee that no other Microsoft product could include the same vulnerable Linux kernel code. erview
CVE‑2025‑22045 is a Linux‑kernel issue in the x86 memory-management code that affects how flush_tlb_range() is used when “zapping” normal PMD entries (that is, PMD entries that point to page-table pages rather than large pages). The bug was fixed upstream by aligning the x86 behavior with the arm64 model so that last‑level invalidation optimizations are not applied when page‑table pages are being removed, closing a class of race/invalid‑invalidation scenarios. The vulnerability has modest but real operational impact: it can lead to inconsistent TLB invalidations that affect availability and correctness on affected kernel builds.
Multiple mainstream distributors and trackers recorded and repackaged the upstream fix into vendor kernels in April–May 2025; advisories and vendor mappings (Debian, Amazon Linux, Red Hat, SUSE, Ubuntu) confirm the nature of the issue and list fixed package releases. These independent vendor advisories are the canonical way to map the upstream commits to the exact kernel package names you must install in your environment.
At the same time Microsoft’s Security Response Center (MSRC) has been publishing product‑level attestations in machine‑readable CSAF/VEX format, starting with the Azure Linux distribution. MSRC’s transparency campaign — a phased rollout of VEX/CSAF attestations beginning in October 2025 — is intended to tell customers, in a machine‑readable way, which Microsoft products include which upstream components and what the attested status is (Known Affected, Not Affected, Under Investigation, Fixed). That program explains why MSRC’s CVE pagf, that “Azure Linux includes this open‑source library and is therefore potentially affected,” and promises updates to the CVE/VEX mapping if additional Microsoft products are identified as carriers.
Crucially, the sentence is not saying “only Azure Linux includes it” or “no other Microsoft product can include the library.” Microsoft’s VEX rollout is phased and product‑by‑product; the attestation reflects the inventory work completed so far, not a global scan of every Microsoft artifact. In short: absence of a VEX entry for product B is not proof that product B is safe — it is simply not yet attested.
However, VEX’s phased rollout produces practical gaps. Until Microsoft has inventoried every product family and published attestations for them, many Microsoft artifacts remain in the “unknown” state. Defenders must therefore treat lack of attestation as an unknown, not as evidence of safety — and shouldvel verification (SBOMs, kernel version/config checks) for all deployed images. Several community analyses and operational playbooks emphasize this nuance and advise immediate patching of attested Azure Linux images while concurrently scanning other Microsoft artifacts.
Microsoft’s statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is a useful, defensible starting point — but it was never intended to be the final word for every Microsoft artifact you run. Use MSRC’s VEX/CSAF outputs to automate triage for Azure Linux, and follow through with artifact verification, vendor advisory mapping, and prioritized patching across WSL2, Azure VM images, Marketplace images, and any other Microsoft‑supplied kernels in your environment to close the loop.
Source: MSRC Security Update Guide - Microsoft Security Response Center
CVE‑2025‑22045 is a Linux‑kernel issue in the x86 memory-management code that affects how flush_tlb_range() is used when “zapping” normal PMD entries (that is, PMD entries that point to page-table pages rather than large pages). The bug was fixed upstream by aligning the x86 behavior with the arm64 model so that last‑level invalidation optimizations are not applied when page‑table pages are being removed, closing a class of race/invalid‑invalidation scenarios. The vulnerability has modest but real operational impact: it can lead to inconsistent TLB invalidations that affect availability and correctness on affected kernel builds.
Multiple mainstream distributors and trackers recorded and repackaged the upstream fix into vendor kernels in April–May 2025; advisories and vendor mappings (Debian, Amazon Linux, Red Hat, SUSE, Ubuntu) confirm the nature of the issue and list fixed package releases. These independent vendor advisories are the canonical way to map the upstream commits to the exact kernel package names you must install in your environment.
At the same time Microsoft’s Security Response Center (MSRC) has been publishing product‑level attestations in machine‑readable CSAF/VEX format, starting with the Azure Linux distribution. MSRC’s transparency campaign — a phased rollout of VEX/CSAF attestations beginning in October 2025 — is intended to tell customers, in a machine‑readable way, which Microsoft products include which upstream components and what the attested status is (Known Affected, Not Affected, Under Investigation, Fixed). That program explains why MSRC’s CVE pagf, that “Azure Linux includes this open‑source library and is therefore potentially affected,” and promises updates to the CVE/VEX mapping if additional Microsoft products are identified as carriers.
What the MSRC sentence actually means
Product‑level attestation, not an exclusivity guarantee
Microsoft’s phrasing is deliberately product‑scoped. When MSLinux “includes this open‑source library,” it is stating the result of an inventory exercise for that specific product family — Azure Linux — and declaring that the product should be treated as in‑scope for remediation. That is useful, authoritative, and actionable for customers who run Azure Linux images: patch those images according to Microsoft’s advisory.Crucially, the sentence is not saying “only Azure Linux includes it” or “no other Microsoft product can include the library.” Microsoft’s VEX rollout is phased and product‑by‑product; the attestation reflects the inventory work completed so far, not a global scan of every Microsoft artifact. In short: absence of a VEX entry for product B is not proof that product B is safe — it is simply not yet attested.
Why that distinction matters operationally
If an organization interprets MSRC’s single‑line attestation as exclusive — i.e., “only Azure Linux is affected” — they risk missing other Microsoft‑distributed artifacts that bundle a Linux kernel built from a vulnerable revision (WSL2 kernels, linux‑azure kernels used in certain VM SKUsmages, partner appliances, and more). Build choices, kernel configuration flags, and selective backports determine whether a given artifact actually contains the vulnerable code; those are per‑artifact facts, not universal truths. Several independent community writeups and vendor trackers make this point repeatedly: treat the Azure Linux attestation as high‑confidence for Azure Linux, and treat everything else as “unknown until verified.”Technical anatomy: why the bug matters
What flush_tlb_range() and PMDs are, in plain language
- A PMD (Page Middle Directory) entry may either point directly to a large page (hugepage) or point to a lower‑level page‑table page (the PTE page).
- flush_tlb_range() is a kernel helper that causes the CPU TLBs (translation lookaside buffers) to drop cached translations for a virtual address range. Correct TLB invalidation is essential when the kernel modifies page tables — stale TLB entries can lead to incorrect memory accesses or speculative page‑walk issues.
- The upstream bug arises when flush_tlb_range() on x86 used some last‑level invalidation optimizations in contexts where a PMD is being “zapped” together with its subordinate PTE page. The arm64 implementation explicitly avoids those optimizations for page‑table removal; the fix harmonizes x86 with that safer behavior.
Practical impact and exploitability
Most public trackers classify CVE‑2025‑22045 as a medium/availability‑first issue; the most realistic outcome is reliability problems or service disruption (kernel oops, TLB inconsistency induced crashes) under specific sequences of page‑table operations. Some hypervisor‑paravirtualization paths (e.g., Hyper‑V TLB paravirtualization) and lazy‑TLB CPU handling are where the vulnerable behavior could show up. Public advisories do not show broad remote exploitability; this is primarily a host‑level correctness/availability problem that becomes significant in multi‑tenant or highly dynamic kernel environments.Cross‑checking MSRC’s attestation: independent corroboration
To answer the user’s central question — “Is Azure Linux the only Microsoft product that includes this open‑source library and is therefore potentially affected?” — we must combine the MSRC attestation with independent evidence:- MSRC’s product‑level CVE pages consistently include the same FAQ language stating that Azure Linux includes the implicated upstream component and that Microsoft began publishing CSAF/VEX attestations in October 2025. That language is present across multiple MSRC CVE entries and is documented in MSRC’s blog describing the VEX/CSAF rollout.
- Independent vulnerability trackers (NVD, OSV, distributor advisories from Debian, Amazon Linux ALAntu) document the technical details and list vendor‑specific package mappings, but none of these third‑party trackers make Microsoft‑product‑scope attestation claims. They instead enumerate distributions and vendor packages that include the fix. This corroboration validates the technical content of CVE‑2025‑22045 while making clear that mapping a CVE to a given Microsoft product is a separate, vendor‑specific inventory step.
Where else to look within Microsoft’s estate (realistic carriers)
Microsoft is not a single monolith when it ships Linux‑based artifacts. The following Microsoft artifacts are plausible carriers of upstream kernel code and therefore should be checked individually:- Azure Linux (the attested product) — high priority; MSRC attested this product and published VEX/CSAF entries beginning with the October 2025 rollout. Patch and verify Azure Linux images immediately.
- WSL2 (Windows Subsystem for Linux) kernels — Microsoft publishes the WSL2 Linux kernel source and distributes WSL kernel binaries; whether a specific WSL kernel is vulnerable depends on the shipped kernel revision and configuration. Do not assume WSL2 is safe just because Azure Linux is the only attested product; check your WSL kernel version and update if needed.
- Azure VM images and linux‑azure kernels — some Azure VM SKUs use Azure‑tuned kernels or packaged linux‑azure builds. These are separate build artifacts and may have different backport and patch cadences. Inventory your VM images and AKS node images to identify which kernel binary they run.
- Azure Marketplace and partner images / appliances — these are assembled by publishers and may contain kernels built from upstream revisions that predate fixes. Treat marketplace and partner images as independent artifacts to be inspected or queried.
- Microsoft‑distributed container host images and curated base images — container images themselves do not contain a host kernel, but images used as VM templates or appliances might. Verify the host kernels that actually run the containers.
Practical, prioritized action plan for defenders
If you run Azure Linux or any Microsoft‑distributed artifacts, follow this playbook to turn uncertainty into verified outcomes.- Inventory: enumerate all hosts and images that run Linux kernels in your estate. Prioritize Azure Linux images first (MSRC‑attested), then WSL2 clients, Azure VMs, Marketplace images, AKS node images, and any Microsoft‑supplied appliances. Use package metadata, uname -r, /boot/config-*, and vendor package queries to collect exact kernel package names and versions.
- Consult vendor advisories: map CVE‑2025‑22045 to the exact kernel package versions for each distribution you run (use NVD, OSV and vendor advisories from Debian, Amazon Linux, Red Hat, SUSE, Ubuntu). These mappings are necessary to determine whether the kernel in your image contains the fix.
- Ingest MSRC CSAF/VEX: subscribe to Microsoft’s CSAF/VEX feed and consume product attestations into your vulnerability management pipeline. Microsoft’s VEX entries provide machine‑readable product mappings and are especially useful for Azure Linux automation. Remember: VEX entries indicate what Microsoft has attested so far, not what other products necessarily contain.
- Artifact verification: for each Microsoft artifact you run, verify whether the shipped kernel binary was built from a vulnerable upstream commit and whether the kernel configuration enabled the affected code paths (drivers, options). If you manage your own images, rebuild or patch the kernel with the upstream fix and redeploy.
- Patch and livepatch where available: install the vendor supplied kernel updates or, where r livepatches that carry the upstream fix to reduce reboot windows. Prioritize Azure Linux updates first when MSRC attests them.
- Test hypervisor and paravirtualization paths: because te can involve hypervisor TLB paravirtualization paths and lazy TLB behavior, test affected operations under your hypervisor mix (Hyper‑V, KVM) after patching to ensure the fix behaves properly in your stack.
- Document and monitor: record the kernel package versions and the remediation status in your SBOM/inventory system and mark Azure Linux images as remediated according to Microsoft’s VEX statements. Continue to monitor MSRC VEX updates for newly attested Microsoft products.
Strengths and benefits of Microsoft’s VEX/CSAF approach — and why defenders should still verify
Microsoft’s move to publish CSAF/VEX attestations starting with Azure Linux is a clear net positive: it gives security teams a machine‑readable signal to automate triage and prioritization. VEX files can reduce false positives and speed decisions by indicating whether a specific product image is Known Affected, Not Affected, Under Investigation, or Fixed. For Azure Linux customers this materially reduces time‑to‑remediation and removes guesswork about whether a Microsoft‑published image includes the vulnerable upstream code.However, VEX’s phased rollout produces practical gaps. Until Microsoft has inventoried every product family and published attestations for them, many Microsoft artifacts remain in the “unknown” state. Defenders must therefore treat lack of attestation as an unknown, not as evidence of safety — and shouldvel verification (SBOMs, kernel version/config checks) for all deployed images. Several community analyses and operational playbooks emphasize this nuance and advise immediate patching of attested Azure Linux images while concurrently scanning other Microsoft artifacts.
Risks and pitfalls to watch for
- Attestation confusion: Security teams who misread MSRC’s concise language as exclusive could delay necessary checks for WSL2, linux‑azure kernels, or Marketplace images and thereby leave parts of the estate unpatched.
- Long‑tail artifacts: Embedded images, appliances, and vendor kernels often lag in patch cycles; these are the classic places where vulnerabilities persist. Treat such artifacts as high‑risk if they run kernels that predate upstream fixes.
- Host vs. container confusion: Container images don’t contain the host kernel; vulnerable host kernels remain the root problem even if container images are rebuilt. Remediate both the host kernel and rebuild base images where necessary.
- Automated triage traps: Blindly trusting a single VEX/CSAF feed without artifact verification can give a false sense of security. Use VEX to prioritize, not to replace, artifact checks.
Concluding assessment: the short, actionable answer
- Is Azure Linux the only Microsoft product that includes the open‑source library and is therefore potentially affected by CVE‑2025‑22045? No — not necessarily. Azure Linux is the only Microsoft product Microsoft has publicly attested (via its phased CSAF/VEX rollout beginning October 2025icated upstream component at the time of the attestation, and that attestation is authoritative for Azure Linux images. However, Microsoft explicitly states it will update CVE/VEX mappings if additional products are identified, and the absence of an attestation for other Microsoft artifacts does not prove they are free of the vulnerable code. Treat Azure Linux as confirmed in‑scope and every other Microsoft‑shipped kernel artifact as “unknown until verified.”
- What should you do right now? Patch Azure Linux images immediately. Then run artifact‑level discovery (SBOMs, kernel version and config scans) across your environment to find and remediate other Microsoft kernels (WSL2, linux‑azure, Marketplace images, AKS nodes) that may be carrying the vulnerable upstream code. Ingest MSRC’s CSAF/VEX feeds into your automation pipeline to keep track of Microsoft’s evolving attestations, but do not substitute those feeds for direct artifact verification.
Quick checklist (for incident responders / platform engineers)
- Patch Azure Linux instances now (MSRC‑attested).
- Inventory: collect uname -r, /boot/config-*, and kernel package metadata for WSL2 clients, Azure VMs, AKS nodes, Marketplace images, and appliances.
- Cross‑reference vendor advisories (NVD, Debian, Amazon Linux, Red Hat, SUSE, Ubuntu) to map the upstream fix to packaged kernel versions.
- If immediate reboots are an issue, use vendor livepatch services where available.
- Ingest Microsoft’s CSAF/VEX feed and subscribe to MSRC advisory updates for a continually refreshed product mapping.
- Document remediation status in your CMDB/SBOM and validate with simple behavior tests (smoke tests for guest stability under workloads that exercise page‑table churn).
Microsoft’s statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is a useful, defensible starting point — but it was never intended to be the final word for every Microsoft artifact you run. Use MSRC’s VEX/CSAF outputs to automate triage for Azure Linux, and follow through with artifact verification, vendor advisory mapping, and prioritized patching across WSL2, Azure VM images, Marketplace images, and any other Microsoft‑supplied kernels in your environment to close the loop.
Source: MSRC Security Update Guide - Microsoft Security Response Center
