Microsoft’s public advisory that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate — but it is a product‑scoped attestation, not a claim that Azure Linux is the only Microsoft product that could contain the vulnerable kernel code. erview
CVE‑2025‑22057 is a Linux kernel vulnerability described upstream as “net: decrease cached dst counters in dst_release.” The defect arises from an incomplete change to the dst (destination) lifecycle: a previous fix moved decrementing the dst counter into dst_release to avoid touching freed data, but that change did not correctly handle cached dst entries when CONFIG_DST_CACHE is enabled and when overlay/OVS tunnel scenarios are present. The result can be kernel faults and memory-access problems that show up as oom/rcu/dst-related traces. The vulnerability and its upstream fix are documented in common trackers such as NVD and distribution advisories.
Microsoft’s Microsoft Security Response Center (MSRC) page for the CVE contains a short FAQ-style attestation that calls out the Azure Linux distribution as including the implicated upstream component and therefore being “potentially affected.” That same MSRC wording also states Microsoft’s commitment to publish machine‑readable CSAF/VEX attestations and to update CVE product mappings if additional M later identified as carriers of the same upstream component.
This article explains what that product attestation means in practice, why you should not interpret it as an exclusivity guarantee, and how IT teams should proceed to verify, prioritize, and remediate risk across Microsoft-supplied artifacts in their environments.
When MSRC says “Azure Linux includes this open‑source library and is therefore potentially affected,” it is doing one concrete thing well: it confirms that Microsoft inspected the Azure Linux build outputs and found the upstream code referenced by the CVE, making those specific Azure Linux images and kernels a known carrier and therefore an immediate remediation priority. That is an authoritative, product‑level inventory mapping intended to give Azure customers a clear operational next step.
However, that sentence is not a statement that every other Microsoft product has been exhaustively scanned and found clean. Large vendors ship thousands of artifacts — kernels for VM images, Marketplace images, container base images, WSL2 kernels, managed node images (AKS), vendor agents and SDKs — and the presence of a particular upstream code path is a build‑time property. Absence of an MSRC attestation for another Microsoft artifact is absence of attestation, not proof of absence. Microsoft’s public statement explicitly acknowledges it will update attestations if more artifacts are discovered to contain the vulnerable code.
Key takeaway: treat MSRC’s Azure Linux attestation as a high‑confidence, immediate action item for Azure Linux customers — but do not let it lull you into assuming other Microsoft artifacts are unaffected without verification.
That approach is pragmatic: it immediately helps the customers who run the attested product, and it also provides a machine‑readable dataset (CSAF/VEX) that automation systems can consume. The limitation is that the rollout is incremental; until attestations are published for every artifact a vendor ships, defenders must still perform their own discovery across the estate.
That said, Azure Linux being named in an MSRC attestation does not imply it is the only Microsoft artifact that could contain the vulnerable kernel code. Any Microsoft product that ships a Linux kernel build — WSL2 kernels, Marketplace VM images, AKS node images, Microsoft-published container base images, or platform service kernels — may carry the same upstream code depending on kernel version and configuration. Until Microsoft extends CSAF/VEX attestations to those artifacts, defenders must assume unknown Microsoft artifacts could be affected and verify them artifact‑by‑artifact.
Operationally, prioritize patching Azure Linux images first (per MSRC guidance), then perform artifact discovery, kernel config/version checks, and phased remediation for other Microsoft artifacts in your estate. Use distro advisories and upstream changelogs to identify fixed kernel versions, validate after patching, and instrument monitoring to detect regressions or remaining carriers.
The combination of vendor attestation (Azure Linux), upstream fixes, and distribution updates provides a clear remediation path — but the final mile of security remains disciplined discovery, verification, and patch orchestration across your environment.
Source: MSRC Security Update Guide - Microsoft Security Response Center
CVE‑2025‑22057 is a Linux kernel vulnerability described upstream as “net: decrease cached dst counters in dst_release.” The defect arises from an incomplete change to the dst (destination) lifecycle: a previous fix moved decrementing the dst counter into dst_release to avoid touching freed data, but that change did not correctly handle cached dst entries when CONFIG_DST_CACHE is enabled and when overlay/OVS tunnel scenarios are present. The result can be kernel faults and memory-access problems that show up as oom/rcu/dst-related traces. The vulnerability and its upstream fix are documented in common trackers such as NVD and distribution advisories.
Microsoft’s Microsoft Security Response Center (MSRC) page for the CVE contains a short FAQ-style attestation that calls out the Azure Linux distribution as including the implicated upstream component and therefore being “potentially affected.” That same MSRC wording also states Microsoft’s commitment to publish machine‑readable CSAF/VEX attestations and to update CVE product mappings if additional M later identified as carriers of the same upstream component.
This article explains what that product attestation means in practice, why you should not interpret it as an exclusivity guarantee, and how IT teams should proceed to verify, prioritize, and remediate risk across Microsoft-supplied artifacts in their environments.
Why the MSRC sentence matters — and why it’s limited
When MSRC says “Azure Linux includes this open‑source library and is therefore potentially affected,” it is doing one concrete thing well: it confirms that Microsoft inspected the Azure Linux build outputs and found the upstream code referenced by the CVE, making those specific Azure Linux images and kernels a known carrier and therefore an immediate remediation priority. That is an authoritative, product‑level inventory mapping intended to give Azure customers a clear operational next step.However, that sentence is not a statement that every other Microsoft product has been exhaustively scanned and found clean. Large vendors ship thousands of artifacts — kernels for VM images, Marketplace images, container base images, WSL2 kernels, managed node images (AKS), vendor agents and SDKs — and the presence of a particular upstream code path is a build‑time property. Absence of an MSRC attestation for another Microsoft artifact is absence of attestation, not proof of absence. Microsoft’s public statement explicitly acknowledges it will update attestations if more artifacts are discovered to contain the vulnerable code.
Key takeaway: treat MSRC’s Azure Linux attestation as a high‑confidence, immediate action item for Azure Linux customers — but do not let it lull you into assuming other Microsoft artifacts are unaffected without verification.
Technical context for CVE‑2025‑22057 (concise)
- What the bug affects: the kernel network destination (dst) accounting and cache lifecycle code related to dst_release / dst_cache_destroy paths.
- Trigger conditions: kernel builds with CONFIG_DST_CACHE enabled and deployment models using overlay networking and OVS tunnels are the environments where the cached dst path becomes significant.
- Observable symptoms: kernel oopses or “unable to handle kernel paging request” traces referencing dst_release, percpu_counter_add_batch, rcu_do_batch and related stack frames; potential stability or availability impact under certain workload/teardown sequences.
- Fix: invalidate dst cache entries (so cached dst counters are decremented) in dst_release as well; upstream patch commits address the missing cache invalidation and have been merged into stable kernel trees. Distribution maintainers have issued updates and backports for affected kernel series.
Is Azure Linux “the only Microsoft product” that could be affected?
Short answer: No — not necessarily, and here is why.- Microsoft’s published statement names Azure Linux as a product that includes the implicated upstream component and is therefore potentially affected. That part is factual and actionable for Azure Linux customers.
- Microsoft has also stated it will expand CSAF / VEX attestations and update CVE mappings if it finds additional Microsoft products that ship the same components. That means other Microsoft artifacts could be carriers, but they might not yet be attested publicly.
- Any Microsoft product or image that ships a Linux kernel build can be a potential carrier depending on kernel version, configuration (e.g., whether CONFIG_DST_CACHE was set), and whether the upstream fix was backported. Examples include the WSL2 kernel, Azure Marketplace VM images, AKS node images, container base images published by Microsoft, and any bespoke kernel builds Microsoft uses in platform services. Treat each artifact as an independent verification task until attestations state otherwise.
What defenders must do (practical remediation checklist)
If you run Azure Linux artifacts, or if your estate consumes Microsoft‑provided Linux artifacts in any form, you should move through the following prioritized steps.1. Inventory — find every Microsoft-supplied Linux artifact in your estate
- Identify VMs and images that use Azure Linux (including custom images built from Azure Linux).
- Enumerate AKS node images, Marketplace images, and Marketplace- or provider-published container base images in use.
- Check WSL2 deployments — the WSL2 kernel is a Microsoft-supplied kernel binary in many Windows builds.
- Locate any Microsoft agents or appliances that bundle kernels or kernel modules.
2. Verify kernel version and configuration per artifact
- For running systems: run uname -a and capture the kernel release string.
- Inspect /boot/config-$(uname -r) or zgrep CONFIG_DST_CACHE /proc/config.gz to determine whether CONFIG_DST_CACHE was enabled in the kernel build.
- For image files or container images: extract the kernel package metadata or image manifest to find kernel package versions and config.
- If you find a kernel whose version falls into the range listed by upstream trackers as vulnerable (check distribution advisories), mark it as in‑scope.
3. Prioritize patching and replacement
- For Azure Linux images: apply the updates Microsoft publishes for Azure Linux immediately per MSRC guidance. That remains the highest immediate priority for Azure customers.
- For Marketplace images, AKS node images, WSL kernels, and Microsoft-published container images: follow vendor guidance where Microsoft has published it; if a vendor patch is not available, plan to:
- replace node images with vendor‑patched images; or
- rebuild images with patched kernels; or
- apply kernel updates via your configuration management tooling for VMs and containers that permit kernel upgrades.
- Validate fixes by confirming kernel versions match fixed versions listed in upstream or distro advisories (NVD, Ubuntu, Debian, Red Hat, SUSE, Amazon Linux advisories all list fixed versions or backports).
4. Temporary mitigations where patches cannot be applied immediately
- Avoid workload sequences that stress teardown of net namespaces or heavy use of overlay/OVS tunnels if feasible.
- Constrain privileged untrusted user access to hosts that are not yet patched.
- Monitor kernel logs for dst_release/rcu/dst_cache_destroy traces and set up alerting so you can detect symptomatic crashes before they become widespread.
5. Operational validation
- After patching, reboot hosts where kernel updates were applied (a kernel patch requires reboot).
- Re-run the kernel config/version checks and verify that the system now matches a patched fixed release cited by distributors or upstream.
- For containerized workloads that rely on host kernels, verify the host kernel is patched. If containers use their own kernels in specialized appliance scenarios, validate those kernels independently.
How to check whether an artifact is actually affected (concrete steps)
- On a running Linux host:
- uname -r # get kernel release
- cat /proc/version
- zgrep CONFIG_DST_CACHE /proc/config.gz || grep CONFIG_DST_CACHE /boot/config-$(uname -r)
- On image artifacts:
- Inspect the kernel package version from the image package database (rpm -q kernel or dpkg -l | grep linux-image).
- Cross-reference the observed kernel version against distribution advisories (Ubuntu, Debian, SUSE, Red Hat, Amazon Linux list fixed versions and backports).
- If CONFIG_DST_CACHE is enabled and the kernel version predates the fixed commits referenced in NVD and distro trackers, treat the artifact as in‑scope until updated.
Why vendors often name a single product — and why that still helps
Large vendors commonly publish product‑scoped attestations as they complete inventory work. Naming one product (here, Azure Linux) is an important transparency step: it tells customers where the vendor has finished the audit and where remediation for that product should be focused. Microsoft’s MSRC attestation for Azure Linux does exactly that and commits to extending VEX/CSAF attestations over time to cover additional products.That approach is pragmatic: it immediately helps the customers who run the attested product, and it also provides a machine‑readable dataset (CSAF/VEX) that automation systems can consume. The limitation is that the rollout is incremental; until attestations are published for every artifact a vendor ships, defenders must still perform their own discovery across the estate.
Critical analysis — strengths and risks of Microsoft’s approach
Strengths
- Actionable clarity for Azure Linux customers. Naming Azure Linux is an authoritative, narrow, and clear signal that drives immediate remediation for a specific product family.
- Commitment to machine‑readable attestations. Publishing CSAF/VEX allows large enterprises to automate triage and orchestration of mitigations once the attestations cover the artifacts they consume.
- Alignment with upstream and distro fixes. The CVE, upstream fixes, and distribution advisories provide concrete patch targets; MSRC’s attestation simply maps these upstream facts into Microsoft’s product inventory for Azure Linux.
Risks and limitations
- Attestation is not exhaustive. The most significant risk is misinterpreting product‑scoped attestations as global guarantees. Many Microsoft artifacts could carry the same kernel code depending on build choices. Customers who rely solely on MSRC pages without artifact verification risk leaving unpatched carriers in their estate.
- Time lag in rollout. CSAF/VEX publishing is phased; until attestations exist for WSL, AKS images, Marketplace images and other artifacts, defenders must assume unknown artifacts might be affected.
- Complexity of artifact landscape. The kernel code can be present implicitly via container images, vendor SDKs, or prebuilt binaries; verifying all possibilities requires disciplined inventory processes.
What you should ask Microsoft (if you need formal assurance)
If your compliance or risk program requires explicit attestation for artifacts beyond Azure Linux, Microsoft’s published commitment suggests the following requests make sense:- Request CSAF/VEX attestations for specific artifacts you consume: WSL2 kernel builds, Marketplace images you use, AKS node images, and Microsoft‑published container base images.
- Ask for SBOM or product inventory entries tied to kernel package versions and kernel config flags (e.g., whether CONFIG_DST_CACHE was enabled in the build).
- Where formal assurance is required, open a Microsoft support ticket to request product‑level attestations for a given set of artifacts.
Recommended monitoring and post‑remediation checks
- Establish log detection for the dst_release / dst_cache_destroy / percpu_counter_add_batch stack traces to detect symptomatic crashes.
- After patching and rebooting, confirm the running kernel matches the patched versions listed by upstream and by your distribution’s advisory.
- In environments using OVS and overlay networks, perform controlled teardown tests that previously triggered the issue (if you have a reproducible workload) to ensure the crash does not reappear.
- Use your vulnerability management tooling to track CVE‑2025‑22057 remediation status across assets; map asset owners and remediation windows.
Conclusion — a pragmatic posture for defenders
Microsoft’s MSRC entry for CVE‑2025‑22057 is precise and useful: it confirms Azure Linux includes the upstream kernel component implicated by the CVE and therefore calls Azure Linux artifacts into scope for remediation. That declaration is an important transparency milestone that yields a clear operational priority for Azure Linux customers.That said, Azure Linux being named in an MSRC attestation does not imply it is the only Microsoft artifact that could contain the vulnerable kernel code. Any Microsoft product that ships a Linux kernel build — WSL2 kernels, Marketplace VM images, AKS node images, Microsoft-published container base images, or platform service kernels — may carry the same upstream code depending on kernel version and configuration. Until Microsoft extends CSAF/VEX attestations to those artifacts, defenders must assume unknown Microsoft artifacts could be affected and verify them artifact‑by‑artifact.
Operationally, prioritize patching Azure Linux images first (per MSRC guidance), then perform artifact discovery, kernel config/version checks, and phased remediation for other Microsoft artifacts in your estate. Use distro advisories and upstream changelogs to identify fixed kernel versions, validate after patching, and instrument monitoring to detect regressions or remaining carriers.
The combination of vendor attestation (Azure Linux), upstream fixes, and distribution updates provides a clear remediation path — but the final mile of security remains disciplined discovery, verification, and patch orchestration across your environment.
Source: MSRC Security Update Guide - Microsoft Security Response Center
