CVE-2025-37907 Ivpu Deadlock: Azure Linux Not the Only Microsoft Impact

CVE-2025-37907 (accel/ivpu: Fix locking order in ivpu_job_submit) — Is Azure Linux the only Microsoft product that includes this code?​

Executive summary — short answer

• No. Azure Linux is not inherently the only Microsoft product that could include the accel/ivpu code (the ivpu driver is part of the upstream Linux kernel). However, Microsoft’s public advisory currently lists Azure Linux as the Microsoft product they have identified as including the affected upstream component and therefore potentially affected; Microsoft says it will update the CVE if additional Microsoft products are found to be impacted.

What this means in practice

• The ivpu driver (drivers/accel/ivpu, module name intel_vpu) is maintained in the upstream Linux kernel and is selectable by a kernel configuration option (CONFIG_DRM_ACCEL_IVPU). Distributions and products that ship a Linux kernel built with that option (or that include the intel_vpu module) will carry the code and therefore could be impacted by this CVE until they ship the upstream fix or a vendor backport.
• Microsoft has stated in its CVE advisory that Azure Linux is included and that Microsoft commits to transparency; they will update the CVE if other Microsoft products are identified as impacted. That language indicates that — as of the advisory — Azure Linux is the only Microsoft product they have identified, not necessarily the only Microsoft product that ever could include the code.

Background and context (what the code is and where it lives)

• The ivpu driver implements support for Intel’s on-chip VPU / NPU (variously called VPU, NPU, Intel VPU/IVPU, intel_vpu) and lives in the upstream Linux kernel under drivers/accel/ivpu. Upstream kernel commits and changelogs show the tree and ongoing maintenance of the ivpu driver (new files, fixes, and patches in multiple kernel releases). This is not a Microsoft-developed kernel driver; it is an upstream Linux kernel component used by many Linux kernels.

Technical summary of CVE-2025-37907

• The CVE addresses a deadlock (locking-order) issue in ivpu_job_submit where two locks (the submitted_jobs lock and file_priv lock) could be acquired in inconsistent order by different threads (job submission vs. job-abort/cleanup), producing a deadlock scenario. The fix made in upstream changes the order of locking in ivpu_job_submit to avoid the deadlock. The same description appears in multiple vendor advisories (NVD, Ubuntu, Red Hat summaries, etc..

Why this matters to Microsoft products (and to you)

• Any Microsoft product that ships a Linux kernel built from sources that include drivers/accel/ivpu — and that enables CONFIG_DRM_ACCEL_IVPU (or bundles the intel_vpu module) — would include the affected code. Examples of Microsoft products that could theoretically include such a kernel are:
  • Azure Linux (Microsoft’s Linux distribution for Azure VMs) — explicitly referenced in Microsoft’s advisory as including the open-source library.
  • Microsoft’s Linux kernels used for Windows Subsystem for Linux (WSL) — Microsoft publishes and distributes a kernel for WSL; if that kernel tree or build configuration enabled the ivpu driver then WSL could include it (practical impact depends on kernel version and config). You should not assume WSL is affected without verifying the WSL kernel build/config. (See “How to check” below.
  • Any other Microsoft product that packages or ships a full Linux kernel (e.g., specialized appliance systems, Azure Marketplace images maintained by Microsoft, or Azure IoT/edge appliances using Microsoft-supplied kernels) — only if the shipped kernel build includes the ivpu driver. Microsoft will update the CVE if they discover other impacted products.

Why Microsoft’s wording matters: “identified” ≠ “only possible”

• Microsoft’s public advisory text (and the linked CVE entry) states that Azure Linux is included and that they will update the CVE if other Microsoft products are identified. That phrasing means: they have confirmed Azure Linux in their analysis and will expand the set of affected Microsoft products if/when they confirm additional impact. It does not logically exclude the possibility that other Microsoft products could be carrying the same upstream code — only that Microsoft has not (yet) identified other impacted Microsoft products. In short: currently identified = Azure Linux; possible = others (if their kernels/configs include the driver).

Evidence from upstream and vendors

• The NVD and many Linux distributors have entries for CVE-2025-37907 describing the ivpu deadlock fix in the upstream kernel. Vendor advisories (Ubuntu, Red Hat, SUSE, AWS ALAS, etc. discuss the same fix and state which distribution/kernel packages are patched or unaffected for their platforms. This demonstrates that the vulnerability is an upstream kernel issue and that distribution/kernel vendors have been triaging it for their packages.
• The ivpu driver is present in recent mainline kernels; the kernel config symbol is CONFIG_DRM_ACCEL_IVPU (module intel_vpu). Whether it is built in a particular kernel depends on configuration and distribution choices.

How to determine if your Microsoft-hosted instance/product is affected — checklist and commands

1. Identify which kernel is running in the environment (Azure VM, WSL instance, etc.:
   • uname -a
   • cat /etc/os-release (to identify distro and vendor)
2. Check if the kernel contains the ivpu config symbol (if /proc/config.gz is present):
   • zcat /proc/config.gz | grep CONFIG_DRM_ACCEL_IVPU
   • or (if /boot/config-<version> is available) grep CONFIG_DRM_ACCEL_IVPU /boot/config-$(uname -r)
   • If set to =m or =y, the kernel includes the ivpu code (module or built-in).
3. Search for the module and firmware:
   • lsmod | grep intel_vpu
   • modinfo intel_vpu (will show module details if present under /lib/modules)
   • ls /lib/modules/$(uname -r)/kernel/drivers/accel/ivpu
4. Check for evidence in logs or devices:
   • dmesg | grep -i vpu
   • lspci -nn | grep -i 8086 (Intel vendor ID) — relevant devices (Meteor Lake / Lunar Lake) may appear
5. For WSL:
   • Inside a WSL instance run uname -a and check /proc/config.gz or /boot/config. WSL’s kernel is the one supplied/ecosystem-managed by Microsoft on Windows; if the WSL kernel build includes intel_vpu, the module would be present. Do not assume WSL is affected — verify the kernel build. (If you manage your own WSL custom kernel you should check that custom build.
6. For Azure Linux customers:
   • Follow Microsoft’s advisory for patches and updates for Azure Linux; Microsoft explicitly referenced Azure Linux in its advisory.

Practical remediation options

• If your kernel includes the ivpu driver (CONFIG_DRM_ACCEL_IVPU is set or intel_vpu module present):
  • Apply the vendor’s kernel update that contains the upstream fix (distributors maintain kernel packages with the fix or backport it). See your distro or platform advisory (Ubuntu, Red Hat, SUSE, Azure Linux updates) for patched package versions.
  • If a vendor patch is not yet available, mitigate by:
  • Removing/disabling the intel_vpu module until a patched kernel is available (rmmod intel_vpu and blacklist if safe in your environment), if your workload does not need the device. (Be careful — unloading modules in production can affect dependent services.
  • Avoiding use of workloads that trigger the vulnerable code path (this is a deadlock on job submission/abort; in many environments the driver may be unused).
• For WSL and other Microsoft-provided kernels:
  • Watch Microsoft’s advisory (they said they will update the CVE and advisories if additional Microsoft products are found impacted). If a WSL kernel update is released, apply Windows Update/WSL kernel update as documented by Microsoft.

Recommendations for Azure customers (practical, prioritized)

1. If you run Azure Linux instances: treat the Microsoft advisory as authoritative for Azure Linux and apply the indicated Azure Linux kernel updates from Microsoft as they become available. Confirm by checking the Azure Linux update channel/patch notes.
2. If you run other Linux images on Azure (Ubuntu, RHEL, SLES, etc.: follow your distro vendor’s advisories (Ubuntu, Red Hat, SUSE) and apply kernel updates for your images. The same upstream CVE is tracked by multiple vendors.
3. If you use WSL or other Microsoft-provided kernels: verify the kernel build/config. If the WSL-supplied kernel includes intel_vpu, expect Microsoft to release guidance/updates if WSL is impacted; monitor Microsoft security channels and apply updates via Windows Update / WSL update mechanisms.
4. If you are unsure how your environment was built or whether the module is present, follow the “How to check” commands above to determine presence of CONFIG_DRM_ACCEL_IVPU or the intel_vpu module and then consult vendor guidance.

What Microsoft has said (direct paraphrase)

• Microsoft’s advisory (MSRC) explicitly references the upstream fix for accel/ivpu and says: “Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability? One of the main benefits ... is the commitment to keep it up to date... Microsoft is committed to transparency ... If impact to additional products is identified, we will update the CVE to reflect this.” That confirms Azure Linux is currently the Microsoft product Microsoft has identified in their triage; they will expand that list if/when they identify other impacted Microsoft products.

Authoritative sources and triage channels to follow

• Microsoft Security Response Center (MSRC) update guide for CVE-2025-37907 — Microsoft’s statement about Azure Linux and follow-ups.
• NVD (NIST) entry for CVE-2025-37907 — canonical CVE description mirrored from upstream.
• Ubuntu / Red Hat / SUSE / Amazon ALAS entries — vendor-specific impact and package status for those distributions. (Follow your distro’s advisories for fixes/backports.
• Kernel upstream patch logs / LKML and kernel changelogs that show the ivpu driver lives in drivers/accel/ivpu and where the upstream change was applied. This is useful to identify which kernel versions contain the fix.

Bottom line and final guidance

• Microsoft’s public advisory names Azure Linux as a Microsoft product that includes the affected open-source library; that is a confirmed identification by Microsoft. However, the ivpu driver is upstream kernel code that other Microsoft-distributed kernels (for example, WSL’s kernel or other Microsoft-managed Linux kernels) could also include depending on how those kernels were configured and built. Therefore Azure Linux is not necessarily the only Microsoft product that could include the code — it is simply the only Microsoft product Microsoft has publicly stated they have identified as including the code so far. Microsoft has committed to updating the CVE if they find additional impacted products.

If you want, I can:

• Help you check a specific VM, WSL instance, or image (tell me the uname -a and whether /proc/config.gz exists or paste the kernel config) and I will analyze whether that kernel likely includes the ivpu driver.
• Watch the MSRC CVE entry and collect and summarize updates (I can provide a short monitoring brief if you want to be notified when Microsoft updates the CVE with additional affected products).
• Produce a short runbook your ops team can use to triage and remediate potentially affected hosts (commands, checks, patch priorities, testing suggestions).

References (select upstream and vendor sources used)

• Microsoft Security Response Center — CVE-2025-37907 advisory (MSRC update guide).
• NVD — CVE-2025-37907 description.
• Ubuntu security notice: CVE-2025-37907.
• Red Hat / Rapid7 CVE summary for kernel accel/ivpu.
• Kernel changelogs / LKML showing drivers/accel/ivpu in mainline kernels and recent ivpu patches.

Would you like me to:

• Run the exact kernel-config/module checks for a specific host (paste uname -a and the output of zcat /proc/config.gz or /boot/config-$(uname -r), or
• Create a one-page runbook your security team can use to triage and patch Azure-hosted Linux VMs and WSL instances?

---

Source: MSRC Security Update Guide - Microsoft Security Response Center