CVE-2025-38389: Azure Linux i915 Patch and Verification Guide

Microsoft’s public advisory on CVE-2025-38389 names the Linux kernel’s Intel GPU driver (drm/i915) as the locus of a bug that can leave a timeline object referenced after an allocation failure — and Microsoft has stated that, today, Azure Linux is the Microsoft product they have confirmed to include the affected open-source library; they will update the CVE if other Microsoft products are found to include the same code. This article explains the vulnerability, lists the kernel versions and vendor patches where the fix has landed, evaluates Microsoft’s statement, and provides practical, verifiable steps IT teams and administrators should take to determine whether any Microsoft product in their environment is exposed and how to remediate it.

Background / Overview​

The code at the center of CVE-2025-38389 lives in the Linux kernel’s Intel GPU driver — commonly referred to as drm/i915. The defect occurs in the context of ring submission and context allocation: when a VMA (virtual memory area) allocation fails during the path that gets a reference to the engine’s legacy timeline, the code can wind up holding a reference that is never released. The result observed in continuous-integration (CI) runs and testbeds was warning and panic-like traces at driver unbind time and leaked objects during shutdown. The fix reorders the operations so the timeline reference is taken only after the VMA allocation succeeds, preventing the stuck reference.
Why this matters: a held kernel object tied to GPU timelines and status-page VMAs can prevent clean driver unbind and object teardown, potentially causing resource leakage, instability, or driver cleanup failures on systems that exercise the problematic code path. The problem is not an immediate remote code execution vulnerability — it’s a local kernel resource / driver correctness bug — but it is still rated with a medium-severity profile and has practical impact in test and CI environments and potentially on shared infrastructure that loads/unloads i915 frequently.
Key technical facts that you can verify in your environment:

• The flaw was tracked as CVE-2025-38389 and publicly announced alongside upstream kernel commits.
• The fix was merged into stable kernel trees; fixed kernel points include backports in the 5.4, 5.10, 5.15, 6.1, 6.6, 6.12 and later series.
• Distributions and vendors have issued patches and advisories; many mainstream vendors have backported fixes into their kernels or published advisories with fixed package versions.

---

The short answer to the user's question​

• Official Microsoft position (public advisory): Azure Linux is the Microsoft product they have identified as including the open-source library that contains the i915 code path referenced by CVE-2025-38389. Microsoft has stated that they publish CSAF/VEX information and that they will update the CVE entry if impact to additional Microsoft products is identified.
• Practical security answer: No vendor statement yet conclusively names other Microsoft products as affected. However, Microsoft operates other codebases that include or consume Linux kernel components (notably the WSL2 kernel distributed for Windows Subsystem for Linux), and the presence or absence of the i915 driver depends on the exact kernel build/configuration shipped. Therefore — while Azure Linux is the only Microsoft product publicly confirmed as including the affected code at this time — other Microsoft-distributed kernels (or customer-controlled kernels distributed for or by Microsoft products) could include drm/i915 depending on build choices. Those should be checked.

Put plainly: Microsoft has publicly named Azure Linux as the known inclusion. That is the current authoritative claim; but whether other Microsoft products include the i915 driver depends on their shipped kernel configuration and module set — and that must be verified for each product/version.

---

Deep dive: what the vulnerability actually is​

What goes wrong​

• The bug occurs when a sequence that performs ring submission first obtains a reference to the engine’s legacy timeline and only then allocates a context-engine VMA.
• If the VMA allocation fails (for example because an internal call was interrupted by a signal), the function returns an error but leaves the timeline reference held.
• On subsequent submits, another timeline reference will be obtained; on successful execution only the last one is released. The previously held reference remains, leaving the timeline and its underlying VMA object held indefinitely.
• On driver unbind or module unload this can surface as warnings (dev_priv->mm.shrink_count-related WARN_ON), object leak messages during slab shutdown, or other cleanup failures and kernel warnings.

Where the fix was applied​

• The upstream kernel fix changes the ordering so the timeline is referenced only after the VMA allocation succeeds. This prevents a timeline reference from being left held when allocation errors occur.

Affected code path and scope​

• The defect is specific to the Intel i915 driver (the drm/i915 subsystem).
• It is tied to ring submission and the context allocation path (and not to unrelated submission methods that use separate allocation flows).
• Not all platforms will exercise the exact error path in normal use — the original observations came from CI test harnesses that intentionally interrupt or exercise IOCTLs and driver unbinds. Nonetheless, any kernel that builds and loads the i915 driver with the affected commits is logically susceptible.

---

Affected kernel versions (practical verification list)​

The upstream Linux kernel security announcement and stable backports identify the introduction point and the fixed points (these are the canonical milestones you should check):

• Issue introduced in 5.4 with the commit that created the problematic code path; fixed backports are present in:
• 5.4.296 (stable backport)
• 5.10.240
• 5.15.187
• 6.1.144
• 6.6.97
• 6.12.37
• 6.15.6
• 6.16-rc5 (developer tree / release-candidate)
• Vendors and distributions may provide other backports into their maintained kernel branches; verify your particular distro’s advisory.

If your kernel version is at or above one of the listed fixed versions for the same major stream — or your vendor has applied the backported patch — you are not affected by this specific code-path bug. If you run a vendor kernel that remains on a pre-fix point (or have cherry-picked downstream patches absent the fix), you remain exposed.

---

Microsoft’s statement and what it means​

Microsoft’s public advisory for CVE-2025-38389 made two important claims:

• Microsoft has confirmed that Azure Linux includes the open-source library code in question and is therefore potentially affected.
• Microsoft commits to transparency (publishing CSAF/VEX notices) and will update the CVE if additional Microsoft products are found to include the same library.

How to interpret that in operational terms:

• Microsoft’s advisory identifies the product they have already audited and verified: Azure Linux. If you are running Azure Linux images in Azure, treat this vulnerability as relevant and follow vendor guidance to patch kernels as recommended.
• Microsoft’s wording does not logically exclude other Microsoft products from containing the same code; it simply says Azure Linux is what they have identified so far. The follow-up sentence (“If impact to additional products is identified, we will update the CVE”) is an explicit commitment to update when/if additional Microsoft products are verified as including the vulnerable code.
• That means customers and administrators must not rely on the single statement as a blanket assurance that other Microsoft products (notably WSL2 kernels or Microsoft-built kernel artifacts) are not affected; instead, they must verify the presence of the i915 driver and its version in each Microsoft-supplied kernel instance they run.

---

Are other Microsoft products likely to include drm/i915?​

Consider these broad categories of Microsoft software that ship or reference Linux kernel components:

• Azure Linux (explicitly confirmed) — Microsoft has confirmed Azure Linux contains the open-source library that includes drm/i915.
• WSL2 (Windows Subsystem for Linux) — Microsoft publishes the WSL2 kernel sources and prebuilt binaries; whether a given WSL kernel includes or builds the i915 driver depends on the WSL kernel configuration used for the release or the custom kernel you install. Historically, the WSL kernel ships with a tailored configuration that focuses on virtualization and guest features, and Microsoft’s kernel includes virtual GPU support (e.g., virtio/dxgkrnl integration). Some WSL kernel builds include more module support in order to support broader workloads; in those builds the i915 driver might be present as a module or built-in. Because WSL2 uses a Microsoft-distributed kernel image, it should be explicitly checked for presence of i915, but Microsoft has not published a blanket statement that WSL is affected for this CVE.
• Azure Marketplace images / Linux VMs — Azure hosts many vendor distributions as VM images; Microsoft does not generally “ship” the upstream vendor kernels, but Azure images do include vendor kernels. When Microsoft says “Azure Linux includes the library,” that refers to Microsoft’s own Azure Linux distribution images. Customer VMs running vendor-supplied kernels are governed by the respective distro vendor advisories, not Microsoft’s.
• Other Microsoft products that embed or ship Linux components — these are rare, but include research/hobby projects, internal kernel ports, or packaged VHDs. The only authoritative way to know is to check the actual kernel/module list shipped by each product.

Conclusion: it’s plausible that other Microsoft-shipped kernel artifacts (most notably WSL2 kernels) may include the i915 driver depending on their config. The safe operational posture is to verify the presence of i915 on each Microsoft-supplied kernel you run (see the verification steps below).

---

How to check whether a Microsoft-supplied kernel (or any Linux instance) includes the affected driver​

Below are short, practical checks you can run on machines (or in WSL instances) to see whether they include drm/i915 and whether the kernel version is patched.
1. Check the running kernel version

• uname -r
• Use this to correlate against the fixed version numbers above.

2. Check if i915 is present as a loaded module

• lsmod | grep i915
• If i915 appears, the module is loaded. That is a strong sign that the machine could exercise the vulnerable code path (subject to kernel version and backport status).

3. Check for the kernel configuration used to build your running kernel

• zcat /proc/config.gz | grep -i DRM_I915
• or if /proc/config.gz is absent:
• grep CONFIG_DRM_I915 /boot/config-$(uname -r) || zgrep CONFIG_DRM_I915 /boot/config-$(uname -r)
• If the result is CONFIG_DRM_I915=y or =m, the kernel was built to include the driver (built-in or module).

4. Inspect module version and modinfo

• modinfo i915
• This will show the version string for the i915 module provided in your kernel image.

5. For WSL:

• Launch your WSL instance and run the above checks; WSL inherits the Microsoft-supplied kernel image unless you have set a custom kernel path in your .wslconfig; check uname -r and test the module presence. WSL can also run with a custom kernel that you install yourself; in that case, the check is the same but applies to the custom kernel you configured.

If the kernel is pre-fix (older than the fixed versions above) and the driver is present, prioritize patching or upgrading.

---

Recommended remediation and verification steps for administrators​

• Immediately check the Microsoft products and Linux instances you control (Azure Linux VM images, WSL instances, on-premises kernels supplied by Microsoft images) for the presence of i915 and confirm the kernel version.
• Apply vendor patches:
• For Azure Linux images, follow the Microsoft-supplied remediation and kernel updates distributed through Azure’s update channels.
• For WSL: if a Microsoft-published WSL kernel update includes the backport, apply the WSL update; if you run a custom WSL kernel, rebuild or update the kernel with the patched commits included.
• For other vendor images (Debian, Ubuntu, Amazon Linux, VMware Photon, etc., follow the respective vendor advisories — many vendors already backported this fix into their kernel packages.
• If you cannot immediately update, mitigate exposure by:
• Avoiding workloads that repeatedly load/unload the i915 driver or perform test harnesses that exercise driver unbinds and interrupts.
• In multi-tenant or shared CI systems, schedule kernel updates during maintenance windows and monitor for kernel warnings or leak messages in dmesg related to i915 cleanup.
• After patching, verify the fix:
• Re-run the checks above to confirm updated kernel versions or patched module versions.
• Confirm that the specific kernel release in your environment includes the fixed commit or is equal/higher than the fixed kernel versions.

---

Operational risk assessment​

• Likelihood: For typical desktop or server workloads, the specific failing path (a VMA allocation interrupted by a signal during ring submission followed by an immediate driver unbind) is not common. The initial reports surfaced in test CI harnesses and IGT test suites that exercise interrupt scenarios. That said, any environment that performs heavy GPU control operations, unbinds, or uses automated test harnesses could reproduce the faulty path.
• Impact: The vulnerability is a kernel driver correctness bug that can lead to resource leaks and driver cleanup failures. In production server environments this can cause instability or require reboots to recover in the case of unreleased driver objects. It is not characterized as an immediate privilege-escalation or remote-code-execution vulnerability, but any kernel bug that destabilizes the platform is significant for reliability and security posture.
• Attack surface: The vulnerability is not something an unauthenticated remote actor can trivially exploit in most configurations. However, on multi-tenant compute nodes or CI systems where untrusted code can exercise GPU IOCTLs, the exposure surface rises — malicious or poorly written workloads could trigger the failing path.

Summary: Medium risk that is more important in high-density CI and GPU-accelerated multi-tenant environments than for isolated desktops. Still, patching is recommended.

---

Critical analysis of Microsoft’s handling and transparency​

Strengths:

• Microsoft publicly acknowledged Azure Linux as including the vulnerable open-source library and committed to transparency by publishing vulnerability exchange format (CSAF/VEX) notices.
• The company committed to updating the CVE if additional product impact is discovered, which is an appropriate and responsible stance.

Potential gaps / risks:

• The advisory’s wording may lead some customers to assume that “only Azure Linux” is involved; that would be a risky assumption for organizations that also rely on other Microsoft-distributed kernels (notably WSL) or run Microsoft-provided images where kernel module presence depends on configuration.
• Microsoft’s advisory left room (explicitly) to update the CVE if more products are found affected — this is good practice, but it places the onus on customers and administrators to verify Microsoft-supplied artifacts proactively rather than relying on a blanket exclusion.

Practical recommendation:

• Treat Microsoft’s statement as the current authoritative identification (Azure Linux), but do not treat it as an exhaustive declaration that other products are unaffected. Perform the verification checks in environments using WSL2, Azure Marketplace images, and any Microsoft-supplied kernel artifacts.

---

Checklist for Windows/Hybrid environments (actionable steps)​

• Inventory:
• Identify all Windows hosts that run WSL2 and record their WSL kernel version and whether they use the Microsoft-supplied kernel or a custom kernel.
• Identify Azure VMs running Azure Linux or Microsoft-maintained Linux images.
• Verify:
• In each Linux instance: run uname -r, lsmod | grep i915, and grep CONFIG_DRM_I915 /boot/config-$(uname -r).
• For WSL: open WSL shell and run the same checks. If you use a custom kernel, inspect that kernel’s .config.
• Patch:
• Apply vendor-supplied kernel updates for Azure Linux and other vendor kernels.
• Update Windows/WSL packages: ensure WSL is up to date via Windows Update/WSL update channels and/or apply a new WSL kernel image if Microsoft publishes one with the fix.
• For custom WSL kernels: rebuild using a kernel tree that contains the i915 fix commit(s) or apply the explicit backport.
• Validate:
• Confirm the kernel version or commit that contains the fix.
• Monitor dmesg and logs for the i915 WARN/WARN_ON or object leak messages after patching.
• Communicate:
• Track Microsoft CVE updates and vendor advisories for any later expansion of affected products.
• For regulated environments, document the checks performed and the remediation timeline in your change control records.

---

Final notes and cautionary guidance​

• Microsoft’s public advisory naming Azure Linux as the known product that includes the library is authoritative for that product, but it is not an exhaustive denial that other Microsoft products do not include the code. Administrators should treat the advisory as accurate but incomplete until the vendor explicitly confirms other product statuses.
• WSL2—because it supplies a full Linux kernel image—must be checked individually. Some WSL kernels may include the i915 driver depending on the WSL version and build configuration; you must confirm the presence of the i915 driver and the kernel version on each WSL host or instance.
• For any vendor-supplied kernel (Azure Linux or otherwise), apply the vendor’s kernel updates. For kernels you control (custom WSL kernels, self-built kernels, or in-house appliances), incorporate the upstream fix or rebase to a fixed stable kernel release.

---

Conclusion​

CVE-2025-38389 is a correctness bug in the Linux drm/i915 driver that can leave a timeline object referenced after a VMA allocation error; upstream fixes are available and many vendors have backported patches into their kernel trees. Microsoft has confirmed Azure Linux as a Microsoft product that includes the affected open-source library and is therefore potentially affected; Microsoft also committed to updating the CVE should they identify impact to additional products. That means Azure Linux customers must treat the issue as relevant and apply vendor updates.
However, do not assume that “Azure Linux only” means other Microsoft-distributed kernels (notably WSL2 kernels) are automatically clear: the presence of the i915 driver is a function of the specific kernel configuration and module set shipped by a product or installed by an administrator. The correct operational posture is to verify each Microsoft-supplied kernel that you rely on, confirm the i915 module presence and kernel version, and apply the appropriate kernel fixes or vendor updates quickly in any workload that loads the i915 driver or performs GPU submissions.
Practical next steps: inventory your Microsoft-distributed Linux kernels (Azure Linux and WSL), run the simple checks listed above to detect i915 presence and versions, and patch to a fixed kernel release or vendor-provided update as soon as reasonably possible. Monitor vendor advisories for follow-up notices from Microsoft and your Linux distribution vendors for any additional backports or mitigations.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center