Azure Linux CVE-2025-37932: Per Artifact Verification for Microsoft Images

Microsoft’s public CVE entry confirms that Azure Linux includes the upstream kernel code implicated by CVE‑2025‑37932 — but that statement is a product‑scoped attestation, not a technical guarantee that other Microsoft products or images cannot also contain the same open‑source component. Microsoft has said it will update the CVE/VEX entry if additional Microsoft products are identified, and organizations must therefore treat Azure Linux as a confirmed hit while independently verifying other Microsoft artifacts in their environments.

Background / Overview​

CVE‑2025‑37932 is a Linux kernel scheduler fix described upstream as “sch_htb: make htb_qlen_notify idempotent.” The underlying problem is a timing/semantic mismatch in HTB’s qlen_notify path: the existing routine could unconditionally attempt to deactivate an HTB class even when it was already deactivated, which could trigger warnings or unstable behaviour when called by callers that expect safe, repeatable notifications (for example, fq_codel_dequeue and qdisc_tree_reduce_backlog. The upstream remediation makes htb_qlen_notify idempotent and adds defensive checks so duplicate or out‑of‑order notifications are benign. This is an availability / stability risk — a local or tenant‑adjacent attack can provoke kernel WARN/OOPS conditions and possibly cause a denial‑of‑service on affected hosts. The fix is small, upstream, and widely backported across distribution stable trees; the practical remediation path is to apply vendor kernel updates that contain the upstream commit and reboot. Vendor advisories (Debian, Ubuntu, Oracle/Red Hat style trackers) map the upstream commits into fixed package versions.

---

What Microsoft actually said (and why wording matters)​

Microsoft’s MSRC advisory text for the CVE states (in essence) that Azure Linux includes this open‑source library and is therefore potentially affected, and that Microsoft began publishing machine‑readable CSAF/VEX attestations in October 2025; it also committed to update the CVE if additional Microsoft products are found to include the same component. That phrasing is deliberate: it documents the result of Microsoft’s inventory of Azure Linux artifacts and establishes a mechanism (VEX/CSAF) for expanding that inventory over time. Two points to emphasise from Microsoft’s wording:

• The attestation is product‑scoped: it asserts what Microsoft has validated for Azure Linux — nothing more. Treat the VEX/CSAF entry as authoritative for that product.
• The attestation is not an exclusionary statement about every Microsoft SKU: absence of a VEX statement for another Microsoft product does not mean the product is free of the implicated code. Microsoft explicitly promises to update the CVE/VEX record if further products are found to be carriers.

These two facts are why the short, practical answer to the user question is: No — Azure Linux is the only Microsoft product Microsoft has publicly attested so far, but it is not necessarily the only Microsoft product that could include the vulnerable code. Treat Azure Linux as confirmed in‑scope; treat other Microsoft images and components as unverified until either Microsoft’s VEX feed expands or you verify the artifact yourself.

---

Technical context: why a single attestation doesn’t prove exclusivity​

Kernel code inclusion is an artifact‑level property. Whether a given binary or image contains a particular upstream source file depends on multiple build‑time factors:

• The exact kernel version and upstream commit range used when building the kernel. Different upstream commits include or exclude fixes and changed behaviour.
• The kernel configuration (CONFIG_*) used for that build: many parts of the networking scheduler are configurable; the same driver could be compiled in, built as a module, or omitted.
• Any downstream vendor backports or backport omissions: vendors frequently backport fixes into long‑lived kernel branches differently, so numeric kernel versions are not always a reliable indicator of whether a patch is present.

Consequently, two Microsoft artifacts — for example, an Azure Linux image and a WSL2 kernel shipped with Windows, or a linux‑azure kernel used for specific VM SKUs — can include different subsets of upstream code. The presence (or absence) of CVE‑2025‑37932 in those artifacts is therefore a per‑artifact fact, not a product‑wide inevitability.

---

Cross‑checking the public record (what independent sources show)​

To validate the technical and operational picture we can cross‑check multiple authoritative sources:

• NVD & distribution trackers: the NVD and vendor trackers document CVE‑2025‑37932 and describe it as a scheduler/htb idempotency fix; Debian and Ubuntu map fixed package versions where backports were applied. These pages confirm the upstream nature of the defect and that vendors have shipped patches into stable trees.
• Kernel upstream commit history and CVE mirrors: multiple stable kernel commit IDs and upstream diffs are available for the change; these are the true technical ground truth for verifying whether a specific kernel build contains the patch. Administrators should match vendor package changelogs to those commit IDs rather than rely on kernel version numbers alone.
• Microsoft’s own MSRC advisory and VEX/CSAF rollout documentation: Microsoft’s advisory explicitly lists Azure Linux as the Microsoft product that “includes this open‑source library and is therefore potentially affected,” and Microsoft’s October 2025 blog explains the phased VEX/CSAF rollout beginning with Azure Linux. Those two corporate statements combined explain Microsoft’s current posture and the mechanism they are using to expand attestations.

Cross‑referencing these independent sources establishes three concrete truths: the bug is upstream in the Linux kernel scheduler; fixes are upstream and landed in multiple stable branches; Microsoft has attested Azure Linux specifically and will expand attestations over time.

---

Operational impact: who should be worried​

The practical risk model for CVE‑2025‑37932 is driven by where and how the vulnerable scheduler code is used:

• High priority (patch urgently): multi‑tenant infrastructure and cloud hosts (including public cloud VM templates), NFV platforms, CI runners, and network appliances — anywhere that untrusted tenants or workloads might be able to perform netlink/tc operations or otherwise manipulate qdiscs. A single kernel OOPS can destabilize an entire host and impact all tenants.
• Medium priority: network gateways, routers and specialized appliances that use classful qdiscs (HTB, DRR, HFSC, netem) in production; these devices can be triggered by local management plane operations or specific traffic patterns that exercise qdisc accounting.
• Lower immediacy: single‑user, locked‑down desktops or servers that do not grant untrusted users the ability to run tc/netlink or create unprivileged containers with NET_ADMIN capability. These systems should still be tracked and updated in normal maintenance cycles.

---

Practical verification: how to determine whether a Microsoft artifact you run is affected​

Because Microsoft’s VEX statement covers Azure Linux only so far, operators must verify other Microsoft artifacts directly. Use the following artifact‑level checks:

• Check the kernel package changelog and distribution advisory for the exact upstream commit(s) that remediate CVE‑2025‑37932; vendors usually note the upstream commit IDs in their changelogs. If the commit IDs are present, the package is fixed.
• On a running system, collect:
• uname -a and kernel build ID (verify which kernel binary is running).
• The kernel config used to build that kernel (often available at /proc/config.gz or via packaged configs). Check whether the scheduler and specific qdisc code are built‑in or modular.
• Loaded modules and qdisc support (tc qdisc list, lsmod).
• If you have a vendor‑supplied Microsoft artifact (for example, a WSL2 kernel binary or linux‑azure package), consult the artifact’s published SBOM/VEX/CSAF entry (if available), package changelog, or the Microsoft VEX feed to see whether that artifact is listed as “Known Affected”, “Fixed” or “Not Affected.” Microsoft has begun publishing machine‑readable attestations for Azure Linux and plans to expand coverage.

If any artifact cannot be positively matched to a fixed commit or to Microsoft’s attestation, treat it as unverified and prioritize patching/mitigation.

---

Short‑term mitigations when patching cannot be immediate​

If you cannot immediately deploy a patched kernel, use compensating controls to reduce exposure:

• Restrict who can run tc and modify qdiscs: use sudoers, RBAC, orchestration lockdowns, and runtime limits to prevent untrusted users or tenants from calling netlink/tc.
• Harden container runtimes: drop NET_ADMIN from untrusted containers and avoid giving tenants privileged capabilities that allow qdisc manipulation.
• Isolate critical workloads from shared hosts until the kernel is patched: move them to nodes where you have full control and a validated kernel build.

These mitigations do not replace a kernel update — they are temporary risk‑reduction measures that buy time until you can patch and reboot.

---

Recommended remediation playbook (operational checklist)​

• Inventory: identify all hosts and images that run Linux kernels which could include classful qdisc support (HTB/DRR/HFSC/netem). Use configuration management to gather uname, kernel build IDs, and package changelogs.
• Vendor advisory check: consult your Linux distribution and Microsoft‑supplied artifact advisories; match upstream commit IDs if available. Remember: distribution backporting policies differ — a kernel version number alone does not guarantee the fix is present.
• Test: validate patched kernels in a staging environment using safe reproducer guidance from upstream and vendors; do not run reproducer sequences on production hosts.
• Patch and reboot: apply vendor kernel updates that contain the upstream fix and reboot into the patched kernel as soon as practical. This is the only definitive remediation.
• Monitor: after patching, check kernel logs (dmesg / journalctl -k) for residual net/sched WARNs or OOPS entries and confirm no reproducer behaviour. Preserve vmcore and kernel artifacts if you observe crashes for forensic analysis.

---

What to do specifically about Microsoft artifacts (WSL, linux‑azure, Marketplace images, AKS)​

Microsoft distributes many distinct artifacts that include Linux or Linux‑adjacent components. Azure Linux is the product Microsoft has attested publicly so far; for any other Microsoft artifact you should:

• Treat Microsoft’s VEX/CSAF feed as the authoritative attestation list for any product Microsoft has declared. If an artifact is not listed, do not assume it is safe; verify directly.
• For WSL2: check the WSL kernel binary version that Windows is shipping on your machines and compare its build ID / kernel config to the upstream commit that fixes CVE‑2025‑37932. WSL uses a Microsoft‑distributed kernel binary that may differ from Azure Linux builds. If uncertain, treat the WSL kernel as unverified until you confirm the presence of the fix.
• For linux‑azure / curated Marketplace images / AKS node images: each image is a separate artifact; check the image’s package changelogs or SBOM to validate whether the fix is present. Use orchestration automation to pull artifact metadata and validate package changelogs at scale.

Microsoft’s phased VEX rollout is intended to make this process easier over time — begin by consuming Microsoft’s machine‑readable VEX/CSAF files and incorporate them into your vulnerability triage pipeline as coverage grows.

---

Risk analysis and critical appraisal of Microsoft’s attestation approach​

Microsoft’s choice to begin VEX/CSAF attestations with Azure Linux is pragmatic: it lets Microsoft pilot tooling and processes on a single product family before scaling to the many other artifacts the company distributes. That is sensible operationally, and it increases transparency for Azure Linux customers immediately. Strengths

• Actionable clarity for Azure Linux: customers running Azure Linux now have a machine‑readable attestation they can programmatically ingest and act on.
• Phased rollout reduces errors: starting with one product reduces the chance of misattributing component presence across Microsoft’s broad product set.

Risks and residual concerns

• Attestation incompleteness during rollout: until Microsoft’s VEX feed covers other artifacts, customers cannot rely solely on Microsoft’s attestations to determine whether Microsoft‑distributed images in their environment are affected. Absence of an attestation is not evidence of absence.
• Per‑artifact complexity: Microsoft and other large vendors produce many similar but distinct artifacts; customers must still do artifact‑level verification (SBOMs, kernel config checks, package changelogs) to reach full assurance.

Where Microsoft’s statement could be misconstrued: a rushed reading of the line “Azure Linux includes this open‑source library and is therefore potentially affected” could lead some to believe Microsoft has checked all its products. The available evidence — the explicit promise to update the CVE/VEX if additional products are identified — shows Microsoft intended the statement to be product‑limited. That nuance matters operationally.

---

Bottom line and immediate action items for operators​

• Treat Azure Linux as confirmed in‑scope for CVE‑2025‑37932 and apply vendor patches for Azure Linux images immediately per Microsoft guidance.
• For every other Microsoft artifact in your estate (WSL kernels, linux‑azure kernels, AKS/Marketplace images, partner appliances), do not assume they are unaffected just because they are not listed in Microsoft’s VEX feed. Verify each artifact individually by matching kernel build IDs, kernel config, and vendor changelogs against upstream commit IDs that fix CVE‑2025‑37932.
• If you cannot patch immediately, apply compensating controls: restrict tc/netlink operations, drop container NET_ADMIN capability for untrusted tenants, and isolate critical workloads until patched.

---

Conclusion​

Microsoft’s public attestation that Azure Linux includes the upstream library referenced by CVE‑2025‑37932 is authoritative for Azure Linux and should trigger immediate action by customers who run those images. However, the attestation is product‑scoped; it does not prove exclusivity. Given the per‑artifact nature of kernel builds, organizations that run other Microsoft‑distributed Linux artifacts should assume unverified status and perform artifact‑level checks — or wait for Microsoft’s VEX/CSAF coverage to expand — before concluding any other Microsoft product is unaffected. The simplest, lowest‑risk path remains: verify artifacts, apply vendor kernel updates that include the upstream fix, reboot, and monitor.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center