CVE-2025-37961: IPVS fix and Azure Linux attestation explained

A recent upstream Linux kernel fix for CVE‑2025‑37961 addresses an uninitialized-value (KMSAN) finding in the IP Virtual Server (IPVS) codepath — specifically an uninitialized saddr value in do_output_route4 — and Microsoft’s Security Response Center (MSRC) has published an attestation that Azure Linux includes the implicated open‑source component and is therefore potentially affected. That attestation is authoritative for Azure Linux, but it is a product‑scoped inventory statement rather than a categorical guarantee that no other Microsoft product ever included the same kernel code.

Background / Overview​

IPVS (IP Virtual Server) is a kernel‑level Layer‑4 load‑balancing subsystem used widely for high‑performance service delivery and is commonly integrated into cloud and container networking stacks (including as the kernel component behind Kubernetes’ IPVS mode). The IPVS code lives in the kernel’s net/netfilter/ipvs tree and is enabled in kernels via CONFIG_IP_VS. Because IPVS runs inside the kernel networking transmit path, bugs there can surface as kernel warnings, oopses, or other availability issues. CVE‑2025‑37961 was reported after syzbot / KMSAN traces flagged an uninit‑value being read in do_output_route4 (called from ip_vs_xmit / ip_vs_tunnel_xmit). Upstream maintainers changed an argument usage to avoid reading an input saddr value that should be ignored according to earlier semantics; the fix makes the code use the return/local value (ret_saddr) instead of the uninitialised caller-supplied value. The bug is therefore a correctness / data‑sanitization issue flagged by memory sanitizers rather than a straight remote code‑execution primitive. Multiple distribution trackers and vendor advisories mapped the upstream fix into distribution kernel updates.

---

What the MSRC statement actually says — and why that matters​

Microsoft’s public entry for this CVE includes a short, machine‑readable attestation: “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability.” That language is part of Microsoft’s product‑by‑product CSAF/VEX rollout that began in October 2025 and represents a finished inventory check for Azure Linux — it does not, by itself, demonstrate exclusivity for all Microsoft SKUs. In plain terms:

• The attestation is an authoritative “yes” for Azure Linux: Microsoft inspected the Azure Linux product artifacts and determined the upstream kernel component (or the relevant kernel configuration) is present there, so Azure Linux images are in scope for remediation.
• The attestation is not a universal statement that no other Microsoft product includes the same code. Microsoft explicitly said it will update the CVE/VEX records if additional Microsoft products are identified as carriers. Treat the absence of an attestation for other Microsoft products as “not yet attested,” not as proof of absence.

This distinction is crucial operationally: a vendor VEX/CSAF attestation is a product‑level inventory result — a completed scan for that product family — and not a global inventory of every binary, image, WSL kernel, Marketplace appliance, or bespoke kernel build Microsoft has ever shipped.

---

Technical anatomy of CVE‑2025‑37961 (concise, operationally useful summary)​

What triggered the finding​

Automated fuzzers and sanitizers (syzbot, KMSAN) exercised ip_vs_xmit’s tunnel transmit path and observed a read of an uninitialized value used as the saddr argument in do_output_route4. The commit message referenced by distribution trackers notes that an earlier change (commit 4754957f04f5: “ipvs: do not use random local source address for tunnels”) implied the input saddr should be ignored; because the code still read the original input, the sanitizer reported an uninit‑value and maintainers changed the call to pass the kernel’s computed ret_saddr instead. This is a local correctness bug rather than a classic buffer overflow or use‑after‑free.

Practical impact​

• Class: kernel robustness / KMSAN/uninitialized-value finding.
• Likely observable effect: kernel warnings, KMSAN reports during instrumentation runs; potential functional failures if a route is incorrectly computed because of a stale/uninitialized source-address value.
• Exploitability: generally limited. This class of bug is primarily an availability/correctness issue; converting it into a remote code‑execution or privilege escalation chain would require additional, more exotic conditions. However, any kernel logic bug in a packet transmit path deserves attention in multi‑tenant cloud and container environments because availability effects can be amplified there.

Where the fix lives​

Upstream kernel maintainers applied a small change to the ipvs transmit code so that the actual computed source address (ret_saddr) is used instead of the uninitialized caller value. Distribution maintainers (Debian, Oracle, Amazon Linux, and others) have mapped the fix into kernel updates and advisories, so operators should rely on vendor-supplied kernel packages for remediation.

---

Is Azure Linux the only Microsoft product that could be affected?​

Short answer: No — not necessarily.
Microsoft’s publicly published attestation names Azure Linux because the company completed its inventory for that product family and published machine‑readable VEX/CSAF output indicating the component’s presence. That is valuable, actionable information for teams running Azure Linux images. But the attestation does not mean other Microsoft artifacts (examples below) cannot include the same upstream kernel code; those artifacts simply have not yet been published in Microsoft’s VEX/CSAF inventory or have not been explicitly attested yet.
Potential Microsoft‑supplied carriers to check:

• WSL2 kernel binaries that Microsoft distributes (Windows Subsystem for Linux uses a Microsoft‑built kernel image).
• linux‑azure or other Azure‑tuned kernels used for certain VM SKUs.
• Azure Marketplace VM images and partner appliance images (each image is its own artifact).
• AKS / curated node images where Microsoft or partners ship Linux kernels.
• Any Microsoft agent, appliance, or container image that includes a full kernel binary or vendor‑supplied kernel modules.

The presence of the vulnerable code in any of those artifacts depends on the kernel version, the build configuration (CONFIG_IP_VS, whether IPVS is built-in or a module), and whether a backport or stable‑patch has already been applied. Only an artifact‑level inventory (checking kernel versions, CONFIG settings, and package changelogs) can definitively tell you whether a specific image or SKU is affected.

---

Cross‑checking the claim (independent evidence)​

Multiple independent trackers and vendor advisories confirm the upstream technical finding and list affected package mappings and fixes:

• The Debian security tracker and advisory pages list CVE‑2025‑37961 and the upstream fix in the ipvs transmit path. This provides an authoritative distribution mapping for Debian/Ubuntu packaging.
• Cloud vendor advisories (for example, Amazon Linux ALAS entries) show the CVE and list applicable kernel packages and fix statuses across Amazon Linux variants; other distribution trackers (Oracle, Red Hat, etc. have equivalent entries. These independent mappings corroborate the technical content and confirm the upstream change was accepted and propagated or backported by various vendors.

These independent sources together verify three load‑bearing facts: (1) the CVE exists and references ipvs/do_output_route4 uninitialized saddr, (2) upstream maintainers applied a targeted fix, and (3) distributions are publishing packaged fixes. That cross‑validation supports treating Microsoft’s Azure Linux attestation as accurate for Azure Linux, while enabling customers to use distribution advisories to check remediation status for non‑Microsoft artifacts.

---

Operational guidance: how to verify whether your Microsoft‑supplied artifact is affected​

When a vendor issues a product‑scoped attestation, do not assume other artifacts are safe. Follow this pragmatic checklist to verify affectedness and remediate:

On a running Linux host (VM, container host, WSL)​

• Confirm kernel version:
• uname -r
• Check whether IPVS is present (built‑in or as a module):
• grep -i IP_VS /boot/config-$(uname -r) (or zgrep CONFIG_IP_VS /proc/config.gz)
• lsmod | grep ip_vs
• modinfo ip_vs (if module is present in /lib/modules)
• Inspect vendor changelogs for the kernel package to find CVE‑2025‑37961 or referenced upstream commit IDs:
• Debian/Ubuntu: apt changelog linux-image-$(uname -r) | egrep -i '37961|ipvs|ip_vs'
• RPM-based: rpm -q --changelog kernel | egrep -i '37961|ipvs|ip_vs'
• For WSL2: verify the WSL kernel version and config (Microsoft publishes the WSL kernel repo and config used for prebuilt images).

For offline images (VM images / Marketplace appliances)​

• Mount the image and inspect /boot/config-* and /lib/modules for CONFIG_IP_VS and ip_vs module presence.
• Extract the kernel package changelog or compare kernel binary version and patch level to distribution trackers that list the CVE and fixed commits.

If you cannot patch immediately​

• Limit exposure: restrict access to administrative or tenant capabilities that could exercise IPVS tunnel/forwarding code.
• Isolate: run vulnerable artifacts in isolated networks or dedicated hosts rather than multi‑tenant shared nodes.
• Monitor kernel logs (dmesg, journalctl -k) for unusual WARN_ON_ONCE or KMSAN warnings that reference ip_vs_xmit, do_output_route4, or related callstacks.

This approach is the practical application of the vendor attestation model: treat Azure Linux’s VEX as authoritative for Azure Linux images, but verify every other Microsoft artifact before assuming it is not a carrier.

---

Remediation and patching strategy​

• Apply vendor‑supplied kernel updates: definitive remediation is to install the kernel package that explicitly lists CVE‑2025‑37961 or the upstream commit hashed into the changelog, and reboot into the patched kernel.
• For long‑lifecycle appliances or embedded systems where vendor updates are slow, engage the vendor for backports or mitigations.
• If you maintain custom WSL2 kernels or custom Azure Marketplace images, rebuild or update those artifacts against a kernel that includes the upstream fix.
• Automate VEX/CSAF ingestion: ingest Microsoft’s CSAF/VEX outputs and your distribution’s advisory feeds into your vulnerability management pipeline to reduce time‑to‑remedy. Microsoft has publicly committed to publishing VEX files and updating them as more products are inventoried; automating ingestion shortens the detection‑to‑patch timeline.

---

Strengths of Microsoft’s approach — and the practical risks​

Strengths​

• Transparency for Azure Linux: Microsoft’s early adoption of machine‑readable CSAF/VEX attestations and publishing of Azure Linux inventory provides clear, automatable signals for operators running that distribution. That is a major step forward for cloud customers who rely on timely, machine‑parseable vendor inventories.
• Procedural commitment: Microsoft’s public declaration that it will update CVE/VEX records if additional products are found to ship the same component is a demonstrable commitment to expand coverage over time.

Risks and common misinterpretations​

• Misreading “includes … and is therefore potentially affected” as exclusivity: Some operators take the attestation wording to mean only Azure Linux can be affected. That is incorrect: the attestation documents completed inventory for Azure Linux only and does not mean every other Microsoft product has been scanned. Absence of an attestation is not evidence of absence.
• Artifact variability: Microsoft ships many Linux‑related artifacts (WSL kernels, curated images, Marketplace appliances). Whether they include a vulnerable kernel file depends on build choices — kernel version, CONFIG options, and backporting policy — so each artifact must be inspected.
• Operational blind spots: Automated vulnerability scanners that only consume vendor VEXs will catch Azure Linux hosts quickly but might miss un‑attested Microsoft artifacts until Microsoft expands its VEX coverage or until operators perform independent checks.

---

Recommended short‑ and medium‑term actions for WindowsForum readers and sysadmins​

• Prioritize patching hosts that run Azure Linux images (authoritative VEX says they include the implicated component). Treat Microsoft’s attestation as an immediate signal to remediate those systems.
• Inventory all Microsoft‑supplied Linux artifacts in your environment (WSL2 instances on developer machines, Azure Marketplace VMs, AKS node images, linux‑azure kernels) and apply the verification checklist above to each artifact. Do not assume non‑Azure Linux artifacts are clean.
• In environments where uptime is critical and immediate patching is slow, isolate vulnerable hosts, restrict untrusted local workloads from exercising networking features (tunnels, IPVS), and centralize kernel logs and crash dumps to improve forensics if something manifests.
• Automate: ingest Microsoft’s CSAF/VEX outputs alongside distribution advisory feeds (Debian, Ubuntu, Red Hat, Amazon Linux, Oracle) into your vulnerability management toolchain so new attestations (or changes) are detected automatically. Microsoft has committed to expanding VEX coverage; automation reduces the odds of manual oversight.

---

Final analysis and verdict​

CVE‑2025‑37961 is a focused upstream kernel correctness/KMSAN issue in the IPVS transmit path that was remedied with a small, surgical change upstream. Multiple independent distribution and vendor trackers corroborate the technical details and confirm that fixes have been published or backported in distribution kernel packages. Microsoft’s MSRC attestation that Azure Linux includes the implicated open‑source component is accurate and useful for teams running those Azure Linux images — treat that VEX/CSAF output as the canonical signal for Azure Linux. However, the statement is a product‑scoped inventory result, not a categorical global assertion for every Microsoft artifact or kernel build. Operators must therefore verify other Microsoft‑supplied artifacts individually (WSL2 kernels, Marketplace images, linux‑azure kernels, AKS node images) rather than assuming they are unaffected simply because Microsoft has named Azure Linux in its VEX attestation.
In risk terms: the MSRC approach improves transparency and reduces ambiguity for Azure Linux customers, but it should not lull organizations into a false sense of security regarding other Microsoft artifacts. Effective remediation requires artifact‑level inventory, vendor package‑level checks, and quick application of kernel updates where the distribution or Microsoft supplies them. The combination of vendor VEX data plus independent distribution advisories gives the most defensible route to rapid, accurate remediation.

---

CVE‑2025‑37961 is real, the upstream fix is implemented, Azure Linux has been attested by Microsoft as potentially affected, and other Microsoft artifacts may still be in scope until explicitly inventory‑checked. Operators should treat the Azure Linux statement as a validated signal, but should verify and patch every Microsoft‑distributed Linux artifact in their environment to ensure comprehensive coverage.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center