CVE-2025-38705: Is Azure Linux the Only Microsoft Product Affected?

Headline
Is Azure Linux truly the only Microsoft product that ships the vulnerable drm/amd/pm code (CVE‑2025‑38705)? Short answer, nuance first — no, not necessarily — but the practical impact depends on which Microsoft kernel builds you actually run.
Lead
Microsoft’s MSRC advisory for CVE‑2025‑38705 calls out Azure Linux as the Microsoft product it has validated as shipping the open‑source component that contains the bug. That is an important and actionable attestation for Azure Linux customers. But it is not, by itself, a general proof that no other Microsoft product includes the same Linux kernel code — Microsoft ships multiple Linux kernels and kernel artifacts (for example, the WSL2 kernel, Azure VM/kernel images, and other cloud images) and some of those artifacts contain AMD GPU driver sources (drivers/gpu/drm/amd). Whether any given Microsoft product is affected comes down to the exact kernel build and version shipped for that product. The upstream fixes and the kernel commit identifiers are public; operators should verify their kernels and update where needed. What CVE‑2025‑38705 is (brief technical summary)

• What the bug is: a null‑pointer dereference in the AMD GPU “pm” (power management) code in the amdgpu driver. The bug can be triggered by writing a string without delimiters to certain sysfs interfaces (gpu_od/fan_ctrl or pp_power_profile_mode when using the CUSTOM profile), which can lead to a kernel null pointer dereference (crash).
• Where it lives: drivers/gpu/drm/amd/amdgpu_pm.c (the amdgpu power management code).
• Upstream resolution: kernel maintainers merged fixes and the Linux kernel CVE team assigned CVE‑2025‑38705; fixes were applied into multiple stable branches (commits and the specific kernel versions are published). The bug was fixed in several kernel releases (for example, the relevant fixes are present in kernels 6.12.43, 6.15.11, 6.16.2 and in 6.17-rc1 via the listed commits).

What Microsoft actually said (and how to read it)

• Microsoft’s MSRC entry (the text you quoted in your question) states that Azure Linux “includes this open‑source library and is therefore potentially affected” and that Microsoft began publishing CSAF/VEX machine‑readable impact attestations in October 2025; Microsoft also says it will update the CVE if other Microsoft products are later identified as affected.
• Important reading tip: that wording is a product‑level attestation for the specific Azure Linux family Microsoft has inspected and mapped — it means “we have verified Azure Linux ships the component.” It does not logically or technically exclude other Microsoft products from containing the same component — Microsoft will expand the mapping if/when their internal inventory and build provenance checks discover other SKUs that ship the vulnerable code. In short: a conservative vendor statement, not an exhaustive guarantee.

Is Azure Linux the only Microsoft product that includes that code?

• The strictly literal answer to “Is Azure Linux the only Microsoft product that includes this open‑source library?” is: Microsoft has publicly attested that Azure Linux includes it (so Azure Linux is a confirmed hit), and Microsoft has not (at the time of that advisory) published attestations for other Microsoft products. That is what the MSRC page means.
• The practical/technical answer is: No — Azure Linux is not necessarily the only Microsoft product that could include the amdgpu driver code. Microsoft maintains and distributes other Linux kernel artifacts (notably the WSL2 kernel builds on GitHub, and the kernel images that back certain Azure offerings). The source tree for the WSL2 kernel repository publicly includes the drivers/gpu/drm/amd area, i.e., amdgpu driver files. That means WSL kernel builds could include the same amdgpu component — whether a particular WSL kernel is vulnerable depends on its kernel version and whether it contains the vulnerable commit range.

Concrete evidence and pointers

• Upstream CVE and fixes: the Linux kernel project and the linux‑cve‑announce thread list the CVE, the affected file, and the commits that fix the bug. Those commits were cherry‑picked into stable kernel branches; the published list of fixed releases is the authoritative upstream mapping. If your kernel is older than the listed fixed releases (or your vendor hasn’t backported the fix), you should consider it vulnerable until proven otherwise.
• Microsoft WSL2 kernel: Microsoft’s WSL2 kernel source is public (microsoft/WSL2‑Linux‑Kernel). The repository includes the amdgpu driver code in the drivers/gpu/drm/amd tree (the repo is a Microsoft‑maintained Linux kernel tree used to build the WSL kernel). That’s why a generic “Microsoft ships Windows only” answer is incomplete — Microsoft ships Linux kernels in multiple places. Whether WSL2 you’re running is impacted depends on the WSL kernel release on your machine and whether that release included the vulnerable commit.
• Vendor/distribution advisories and downstream packaging: distributors (SUSE, Ubuntu, kernel maintainers, etc. have already included the upstream fixes or backports in their kernel package updates; major distro advisories list the kernel package versions and backports that fix the issue. That’s how cloud distro packages get patched for Azure VM images and other deployments.

How to determine whether a Microsoft product you run is affected (practical checklist)
This is the operational checklist you should run now — it’s fast, definitive for your hosts and images, and does not rely solely on MSRC product mappings.
1) Inventory: identify all places where Microsoft‑published Linux kernels or Microsoft images run in your environment

• Azure Linux images (your AKS/VM images or Azure‑hosted container hosts)
• WSL2 instances on developer/CI machines where Microsoft’s WSL kernel is used
• Any Microsoft‑published Marketplace or curated images you run (they sometimes include Microsoft‑built or vendor‑built kernel packages)
• If you operate custom images derived from Microsoft base images, those images inherit the kernel packages in the base.

2) Inspect the kernel version (on a running Linux host)

• Run: uname -r
• Check the vendor package: for packaged kernels, check package changelog or vendor advisory to map that kernel package to upstream commits and whether the CVE fix is included.

3) Check whether the AMGPU code is present / whether amdgpu is enabled

• Look for the amdgpu module or the compiled driver files:
• lsmod | grep amdgpu
• grep -R "amdgpu" /lib/modules/$(uname -r) 2>/dev/null
• ls /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/amd 2>/dev/null
• Inspect running kernel config for relevant settings:
• zcat /proc/config.gz | grep -i CONFIG_DRM_AMDGPU
• grep -i CONFIG_DRM_AMDGPU /boot/config-$(uname -r) (if available)

4) Map your kernel to the upstream fix set

• The Linux kernel CVE announcement lists the commits and the stable kernel releases that include the fix (for example, fixes in 6.12.43, 6.15.11, 6.16.2, etc.. If your kernel release is older than the fixes and contains amdgpu, treat it as in‑scope until vendor patches are applied.

5) For WSL users: check the WSL kernel version and update

• In WSL: uname -r to see the linux kernel release
• If you’re using Microsoft’s distributed WSL kernel, Microsoft publishes the source and periodically ships updates; keep the WSL kernel updated in Windows (wsl --update) and monitor the WSL repository for security updates. Because the WSL kernel is an actual Linux kernel image Microsoft ships, it can contain amdgpu bits depending on configuration — verify the kernel on your machine.

6) Image and container scanning

• For container images and VM images, run an image scanner (Syft/Grype, Anchore, Trivy) to identify kernel packages and open‑source components inside images. If you have image registries with Microsoft base images, scan those images and note which kernel packages they include. (Syft/Grype already added or announced support for Azure Linux packages in prior cycles.

Short remediation checklist (what to do now)

• If you run Azure Linux images: treat MSRC’s attestation as a confirmed hit for those images — apply the vendor/patch guidance for Azure Linux immediately (update kernel packages or redeploy patched images).
• If you run WSL2: check your WSL kernel version and update WSL (wsl --update) to pickup Microsoft’s latest WSL kernel where relevant. If you build or distribute custom WSL kernels, rebuild them against the patched upstream commits.
• If you run other Microsoft‑published kernels or Marketplace images: inventory and check them as described above; apply vendor patches or rebuild and redeploy patched images.
• If you cannot patch immediately: remove or restrict exposure to the affected sysfs interfaces (e.g., restrict who can write to gpu_od/fan_ctrl and pp_power_profile_mode) as a short‑term mitigation and monitor for suspicious activity — note that kernel null pointer dereferences typically lead to denial‑of‑service (crash) rather than remote code execution, but they still pose operational risk. Upstream guidance from kernel maintainers emphasizes updating kernels.

Why Microsoft may have named Azure Linux first (context, not blame)

• Practical inventory approach: Microsoft chose Azure Linux as an initial product mapping because it is the Microsoft‑published Linux distribution and kernel artifact family (the “Azure Linux” / CBL‑Mariner lineage) that is easiest to inventory and attest with CSAF/VEX. Large vendors commonly publish product attestations in phases: first the product(s) they have finished cataloging, then others as inventory completes. That is explicitly the process Microsoft describes in its MSRC advisory language: “If impact to additional products is identified, we will update the CVE to reflect this.” The statement is a machine‑readable attestation for specifically the Azure Linux family at the time of disclosure; it is not an exhaustive proof that no other Microsoft artifact could possibly include the component.

What we checked for this article (methodology)

• Upstream CVE and kernel announce thread (linux‑cve‑announce) and OSV/NVD entries to confirm the bug description, affected file, and fixed commits.
• The microsoft/WSL2‑Linux‑Kernel GitHub repository to confirm Microsoft publishes a Linux kernel tree that contains drivers/gpu/drm/amd (i.e., amdgpu sources). That indicates WSL kernels are a plausible vector where Microsoft ships a kernel with the same subsystem.
• Distribution/security advisories (SUSE and others) showing downstream packaging and the “stable‑backports” path for the fixes. These are useful to map vendor kernel package numbers to upstream commits.

Bottom line (what you tell your IT/security team)

• Treat Azure Linux as a confirmed affected Microsoft product (MSRC attested it). If you run Azure Linux images, patch now. Microsoft’s VEX/CSAF output is the authoritative machine‑readable signal for those images.
• Do not assume other Microsoft artifacts are automatically safe simply because they are not yet listed. Any Microsoft‑shipped kernel (WSL2 kernel, Azure kernel packages, Marketplace images that include a Linux kernel) that includes the amdgpu driver and is older than the fixes is at risk. Inventory first, patch second.
• If you run WSL2 in your developer fleet or CI fleet, verify the WSL kernel version — Microsoft publishes the WSL kernel sources and updates; update WSL where needed. If you run custom WSL kernels, rebuild them with patched upstream commits.

If you want, I can:

• Produce a short runbook you can hand to your Linux/Cloud engineering team (commands and steps to inventory Azure images, WSL clients, and VM images, plus exact grep/scan commands and remediation steps).
• Scan a small sample of outputs (for example, a uname -r and ls /lib/modules/… listing you paste here) and tell you whether that specific kernel is newer/older than the fixed releases and therefore likely fixed or still vulnerable.
• Monitor the MSRC CVE entry and update you if Microsoft expands the product mapping (i.e., if they add WSL or other Microsoft products to the CVE record).

Relevant references I used while reporting this (for your investigation)

• Linux kernel CVE announcement and fix commits (linux‑cve‑announce).
• NVD/CVE summary for CVE‑2025‑38705.
• OSV / stable commit mapping and affected commit ranges.
• microsoft/WSL2‑Linux‑Kernel repository (WSL kernel sources; shows presence of amdgpu files).
• Distribution/security vendor advisories (example: SUSE patch notes listing the drm/amd/pm fix).

Short example commands (copy/paste) — how to check a running host quickly

• Show kernel release:
• uname -r
• Show whether amdgpu module is present:
• lsmod | grep amdgpu || true
• ls /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/amd 2>/dev/null | head -n 40
• Show kernel config for amdgpu:
• zcat /proc/config.gz 2>/dev/null | egrep -i 'CONFIG_DRM_AMDGPU|CONFIG_DRM' || grep -i CONFIG_DRM_AMDGPU /boot/config-$(uname -r) 2>/dev/null
• Map kernel to upstream fix: compare uname -r output with the fixed release numbers cited (6.12.43, 6.15.11, 6.16.2). If your kernel is older than the fixed versions and amdgpu is present, plan patching.

Final note on vendor transparency
Microsoft’s adoption of CSAF/VEX (machine‑readable attestations) — which the company began publishing in October 2025 for third‑party components — is meant to make this exact question easier for customers. When Microsoft says “Azure Linux is the product that includes the open‑source library,” treat that as an authoritative, machine‑readable signal for Azure Linux — but follow the inventory steps above to verify other Microsoft artifacts in your environment. Microsoft has committed to updating CVE mappings if additional products are identified as affected; meanwhile, operators should verify and patch hosts proactively. Would you like the short runbook (commands + suggested prioritization) I mentioned, or do you want me to check a specific kernel output you have (paste uname -r and a directory listing of /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/amd) and I’ll interpret it for you?

---

Source: MSRC Security Update Guide - Microsoft Security Response Center