CVE-2025-38361: AMD DRM Patch in Linux Kernel and Azure Linux Attestation

Microsoft’s public advisory for CVE-2025-38361 notes that Azure Linux includes the open‑source library that contains the bug, but that statement is a product‑scoped attestation—not an iron‑clad guarantee that no other Microsoft product ships the same vulnerable code. The Linux kernel fix for this CVE patches a null‑check omission in the AMD DRM display stack (drm/amd/display) where the dce_hwseq pointer can be NULL and must be verified before use; the remediation has been merged into stable kernel trees and distributed by downstream vendors.

Background / Overview​

CVE-2025-38361 addresses a defensive‑coding bug in the AMD GPU display driver area of the Linux kernel. The specific defect is that a hardware sequencing pointer (commonly referenced as dce_hwseq or hws in the code) was used without a null check in some code paths, even though earlier code showed that it can be NULL under certain failure or initialization sequences. The upstream patch inserts the necessary check(s) so that the pointer is validated before dereference, preventing a kernel NULL‑pointer dereference and the resulting oops or driver crash. This class of kernel flaw is primarily an availability and stability issue: a local process that can exercise DRM/amdgpu paths (for example, a compositor, an unprivileged user allowed to access /dev/dri, or code running inside a container with device passthrough) can provoke a kernel oops or GPU reset. Most public advisories treat the bug as a local DoS / robustness vulnerability rather than a direct remote privilege‑escalation or RCE problem; nevertheless, kernel crashes and deterministic resets remain high‑value targets for attackers in multi‑tenant environments. The upstream remediation is small and targeted. The fix was cherry‑picked into stable branches and is surfaced in vendor kernels and distro updates; multiple package trackers (Ubuntu, Debian, Amazon, Oracle and others) list the CVE and the fixed kernel package versions. Operators should treat the patched kernel releases and vendor advisories as the authoritative remediation path.

---

What Microsoft actually said — reading the MSRC wording​

Microsoft’s Security Response Center entry for the CVE includes the succinct sentence you quoted: that “Azure Linux includes this open‑source library and is therefore potentially affected.” That statement is a formal product‑level attestation in Microsoft’s CSAF/VEX model: it affirms Microsoft completed an inventory for the Azure Linux family and found the implicated upstream component present in those images, so Azure Linux is in scope for the CVE and remediation work. Microsoft has also publicly committed to extend its machine‑readable attestations and update the CVE mapping if additional Microsoft products are later discovered to ship the same component.
This phrasing is deliberate and procedural: it confirms what Microsoft has validated so far and explains how Microsoft is publishing that mapping (CSAF/VEX for Azure Linux). It does not assert that other Microsoft products have been exhaustively scanned and declared free of the component. Absence of a VEX/CSAF attestation for a given Microsoft product is therefore an absence of attestation, not positive evidence of absence.

---

Is Azure Linux the only Microsoft product that includes the vulnerable library?​

Short, operational answer:

• Azure Linux is the only Microsoft product Microsoft has publicly attested as including the open‑source component implicated in CVE‑2025‑38361 at the time the advisory was published. That attestation is authoritative and actionable for organizations running Azure Linux images.

Longer, technical answer:

• No — Azure Linux is not necessarily the only Microsoft product that could include the vulnerable Linux kernel code. The underlying source files live in the upstream Linux kernel tree (drivers/gpu/drm/amdgpu and the drm/amd/display subtrees). Any Microsoft‑supplied artifact that ships a Linux kernel build compiled with those components enabled (either built‑in or as loadable modules) could, in principle, include the same code and therefore be within scope until verified or patched. That includes Microsoft’s WSL2 kernel builds, certain linux‑azure kernels used in cloud images, Marketplace appliance images that include a kernel image, or bespoke Microsoft images and appliances that embed a Linux kernel.

Two practical reasons this distinction exists:

• Kernel build configuration is an artifact‑level property: two kernels built from the same upstream source can have very different feature sets based on CONFIG_* flags (for example, whether amdgpu and DRM components are enabled). Presence or absence of a component must be verified per artifact.
• Vendors frequently backport fixes: a distro may ship an older kernel version number but include a vendor backport of the specific upstream stable fix, in which case the binary is not vulnerable even though a naive version‑check might suggest otherwise. Cross‑checking package changelogs and vendor advisories is essential.

---

Independent verification and cross‑checks​

To validate the technical claim that this bug exists and has been fixed upstream, two independent and authoritative trackers are useful:

• The National Vulnerability Database (NVD) and multiple distro security pages record CVE‑2025‑38361 with the description that the display driver must check dce_hwseq prior to dereference. This corroborates the upstream commit message and the class of problem.
• The Open Source Vulnerabilities (OSV) database and distro advisories (Ubuntu, Amazon Linux ALAS, Debian trackers) list affected git ranges and the fixed commit IDs that remove the unsafe dereference, and they enumerate which kernel branches received backports or stable merges. These pages show the same technical summary and give the concrete commit ranges you can match against your kernel artifacts.

Where Microsoft’s statement is concerned, the MSRC wording and Microsoft’s VEX rollout are documented in Microsoft’s advisory flow; multiple independent writeups and enterprise Q&A threads also parse Microsoft’s phrasing and arrive at the same operational conclusion: Azure Linux has been inventoried and marked in scope, but other Microsoft artifacts remain to be inventoried and attested. Use Microsoft’s CSAF/VEX feeds and vendor advisories to automate confirmation for Azure Linux, and apply artifact‑level checks for other Microsoft images you run.

---

Where to look inside your Microsoft footprint — concrete artifact checks​

If your environment uses any Microsoft‑supplied or Microsoft‑managed Linux artifacts, treat the following as your verification checklist. Each item is short, repeatable, and suitable for automation.

• Identify the running kernel:
• uname -r
• Compare the running kernel and vendor package changelog to the distro advisory that maps CVE‑2025‑38361 to fixed kernel packages. Use upstream commit IDs when available to detect backports.
• Check for the amdgpu DRM driver and runtime devices:
• lsmod | grep amdgpu
• modinfo amdgpu (if modules are available)
• dmesg | grep -i amdgpu
• ls /dev/dri or ls /sys/class/drm to see if DRM device nodes exist.
• Inspect kernel configuration:
• If /proc/config.gz is available: zless /proc/config.gz | grep -i DRM_AMDGPU
• If you have access to the kernel build artifact, inspect its CONFIG settings to confirm whether the amdgpu DRM and related drm/amd/display pieces were enabled.
• For WSL2:
• Check the WSL kernel version from inside WSL (uname -r) and determine if you are using Microsoft’s published kernel (default) or a custom kernel via .wslconfig.
• Microsoft publishes the WSL2 kernel source and release tags in the microsoft/WSL2-Linux-Kernel GitHub repository; consult the repo and the WSL release notes to match kernel versions and patches.
• For Azure VMs, Marketplace images, AKS nodes:
• Vendor/guest OS kernel packages are supplied by distro vendors for most marketplace images. Confirm guest patch level via the distro vendor advisory channel (Ubuntu, RHEL, SUSE, etc.. For Microsoft‑maintained images (Azure Linux / linux‑azure kernels), consume Microsoft’s CSAF/VEX feed and the Azure Update Management advisories.
• If in doubt, assume vulnerability until proven otherwise:
• Where artifact inspection is not immediately possible, treat the system as potentially affected and apply conservative mitigations (restrict device node access, enforce strict container isolation, disable unneeded GPU device exposure).

---

Practical mitigations and prioritized actions​

• For Azure Linux customers: follow Microsoft’s remediation guidance without delay. Microsoft’s product‑level VEX/CSAF attestation exists precisely to make Azure Linux triage deterministic and automatable—ingest that feed and roll out the patched kernel images described there.
• For WSL users: ensure Windows Update (or your chosen WSL kernel management path) has applied the latest WSL kernel releases. If running a custom WSL kernel, rebuild or obtain an updated kernel with the upstream fix and replace the kernel used by WSL via .wslconfig. Microsoft’s WSL2-Linux-Kernel repository and release notes are the place to check the kernel trees and tags.
• For Azure VM and AKS customers: rely on guest OS vendor updates. GPU‑enabled VM SKUs vary in how they present GPU hardware (host virtual GPU, passthrough, mediated devices). Confirm the GPU virtualization model for your SKU, then apply guest kernel updates or vendor‑supplied driver stacks as indicated. Restrict untrusted workloads from accessing device nodes.
• Short‑term mitigations where patching is delayed:
• Restrict access to /dev/dri and device nodes via group membership and SELinux/AppArmor policies.
• Avoid untrusted mounting of /dev devices into container workloads.
• Limit use of GPU passthrough for multi‑tenant or CI workloads until patches are applied.

---

Strengths and weaknesses of Microsoft’s attestation approach​

Microsoft’s decision to publish machine‑readable CSAF/VEX attestations for Azure Linux is a pragmatic and positive step for supply‑chain transparency. It gives enterprises a deterministic, automatable signal to reduce false positives and to accelerate patching for a specific Microsoft product family. That is a notable win for customers who rely on Microsoft‑maintained Linux images.
However, this model has operational tradeoffs and risk vectors that must be recognized:

• Strengths:
• Automation‑friendly: VEX/CSAF feeds can be integrated into vulnerability management pipelines to produce high‑confidence triage for Azure Linux images.
• Clear remediation path: product‑level attestations mean Azure Linux customers know exactly which updates to apply and can coordinate patching across fleets.
• Risks / Limitations:
• Phased coverage: starting with Azure Linux means other Microsoft artifacts (WSL kernels, linux‑azure, Marketplace images, appliances) may not be attested yet; absence of attestation is not proof of absence. That leaves a window of uncertainty for enterprises that run mixed Microsoft artifacts.
• Artifact heterogeneity: kernel configuration variability and vendor backports make naive version checks unreliable; operators must inspect kernel configs, modules and package changelogs to be certain.
• Operational complexity for multifunctional products: WSL, for example, ships a Microsoft‑maintained kernel upstream on GitHub, but kernel configuration and module choices evolve per release; a cursory statement that the kernel tree contains the driver does not prove that every shipped WSL kernel binary is vulnerable or safe—per‑artifact verification is still required.

In short: Microsoft’s transparency is helpful and reduces uncertainty for the products it has attested, but it does not remove the need for direct artifact verification across a complex estate.

---

Recommended runbook (concise, for operators)​

• Ingest Microsoft’s CSAF/VEX feed and confirm whether any Microsoft‑supplied artifacts you use are listed as Known Affected or Fixed. Prioritize remediation for Known Affected Azure Linux images.
• For every host or VM that uses Microsoft images or that runs a Microsoft‑supplied WSL kernel, run the kernel checks below and compare against vendor advisories:
• uname -r
• zgrep CONFIG_AMDGPU /proc/config.gz (or inspect build config)
• lsmod | grep amdgpu
• dmesg | grep -i amdgpu
• If a kernel is identified as within an affected range and no backport is present, schedule and test a kernel update or apply the vendor’s fixed kernel package in staging first, then deploy to production.
• Where patching is delayed, restrict access to DRM device nodes, limit GPU passthrough, and enforce tighter container isolation for workloads that could reach /dev/dri.
• Monitor kernel logs for repeated pageflip timeouts, amdgpu oopses, or other GPU driver stack traces; treat those as high‑priority signals for remediation.

---

Caveats, uncertainties, and final risk judgement​

• The Microsoft statement that Azure Linux includes the open‑source library and is therefore potentially affected is true and authoritative for Azure Linux. Customers running Azure Linux should act on Microsoft’s guidance immediately.
• It would be incorrect to infer from Microsoft’s attestation that no other Microsoft product can include the vulnerable code. The Linux kernel code is upstream and may appear in any Microsoft‑built kernel artifact depending on build configuration and backports; items that deserve attention include WSL kernels, linux‑azure kernels, Marketplace images and any Microsoft image that includes a Linux kernel binary. Treat these artifacts as unverified until you can confirm their kernel configuration and patch level.
• If an enterprise needs absolute certainty for all Microsoft artifacts across a large estate, the only deterministic path is either:
• Consume Microsoft’s expanding CSAF/VEX feed as it matures and attests additional product families, and/or
• Perform per‑artifact verification (kernel config, module presence, package changelogs) for each Microsoft image in use.
• Any claim that “Azure Linux is the only Microsoft product that includes the library” is a misreading unless it is qualified precisely as “the only Microsoft product that Microsoft has attested, at this time, as including the component.” This qualification is crucial in risk communication.

---

Conclusion​

CVE‑2025‑38361 is a localized Linux kernel robustness fix in the AMD DRM display code. Microsoft’s public advisory that Azure Linux includes the implicated open‑source library is a useful and authoritative attestation that gives Azure Linux customers a clear, machine‑readable path to remediation. However, the attestation is product‑scoped and does not prove exclusivity across Microsoft’s broader portfolio. Any Microsoft artifact that ships a Linux kernel compiled with the AMD DRM/display components enabled could, in principle, be affected until either Microsoft publishes a VEX/CSAF attestation for that artifact or the artifact is inspected and shown to be patched or configured without the vulnerable driver. Operators must therefore combine Microsoft’s VEX feeds with artifact‑level checks (kernel config, modules, package changelogs) and vendor distro advisories to make defensible, timely patching decisions.
For environments running Azure Linux: prioritize the vendor’s kernel updates and VEX guidance immediately. For the rest of a Microsoft‑sourced Linux footprint (WSL, Marketplace images, AKS/VM images), conduct per‑artifact verification and enforce conservative mitigations until the inventory is complete.
Note: public trackers (NVD, OSV, Ubuntu, ALAS) list the CVE and the upstream commit ranges; use those references to cross‑check your kernel versions and to confirm whether a vendor backport is present. If any claim regarding product impact cannot be verified by artifact inspection or Microsoft’s VEX feed, treat the claim as unverified and follow the conservative mitigations above.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center