Microsoft’s advisory identifies Azure Linux as the Microsoft product currently known to include the affected open‑source component, but that statement is a status update — not a definitive guarantee that no other Microsoft product contains the vulnerable code. The flaw is in the Linux kernel’s drm/msm subsystem (the Qualcomm MSM DRM driver), which is upstream Linux kernel code and can appear in any Microsoft distribution or product that ships a Linux kernel build containing that driver; Microsoft has stated it will update the CVE entry if additional products are found to be impacted.
Background / Overview
CVE‑2025‑39747 is a Linux kernel fix that adds proper error handling for a failed krealloc call inside the drm/msm code path (specifically the function msm_ioctl_gem_info_set_metadata. The patch ensures that allocation failure is handled cleanly (returning -ENOMEM) rather than permitting a NULL‑pointer dereference. This is a defensive, reliability‑focused kernel patch addressing a memory‑management edge case in the Qualcomm MSM DRM driver. The vulnerability lives in a kernel module (drm/msm) that is primarily relevant to Qualcomm SoC platforms and the ARM/Qualcomm driver stack. The MSM DRM driver is maintained as part of the ARM/Qualcomm area of the mainline kernel and is not a generic user‑space library; it is kernel driver code that distributions and vendors may include or exclude when they build kernels for specific targets. Because this is upstream Linux kernel code, any product that ships a kernel containing the drm/msm driver (and a kernel revision prior to the fix commit) is potentially affected — if the driver is present and loaded on the runtime platform. Microsoft’s advisory identifies
Azure Linux as the Microsoft product that currently includes the vulnerable component and is therefore
potentially affected; Microsoft also commits to updating the CVE entry if they find additional Microsoft products that include the same upstream library.
What Microsoft actually said (and what it means)
- Microsoft’s public note identifies Azure Linux as the Microsoft distribution that includes the open‑source library in question and therefore may be affected. The advisory states that Microsoft publishes CSAF/VEX data and will update the CVE if impact to additional products is identified.
- That wording is precise: it reports current Microsoft product mappings, not a universal guarantee about all Microsoft products across every release or SKU. Treat the MSRC statement as a verification of what Microsoft has already found in their inventory and remediation pipeline.
In short: Microsoft has publicly confirmed Azure Linux as the Microsoft product they know includes the vulnerable upstream code, and they will add further Microsoft products to the advisory if/when they find them. That makes
Azure Linux the only Microsoft product currently listed by Microsoft as including the vulnerable component — but it does not prove no other Microsoft product contains the driver.
Why Azure Linux appears in Microsoft’s mapping
Azure Linux is Microsoft’s cloud OS image family (Linux distributions and kernels Microsoft builds, maintains, and publishes for Azure VM images). Because it is a Linux distribution image that Microsoft builds and curates, it is the natural place for Microsoft to detect and map upstream Linux kernel vulnerabilities into a Microsoft product context.
- Azure Linux kernel images (like any Linux kernel build) may include numerous drivers; when a kernel fix touches an upstream driver, Microsoft’s kernel inventories can determine whether their Azure Linux kernel builds include that driver and whether the build used a vulnerable commit range. That inventory process is how Microsoft can confidently mark Azure Linux as “in‑scope” for the CVE and to prepare patches or image updates.
Could other Microsoft products include the same library?
Short answer: yes — technically possible, but unlikely in most mainstream Microsoft products. Reasoning:
- The code in question lives in the Linux kernel (drm/msm), not in a general-purpose userland library. Any Microsoft product that packages or ships a Linux kernel build could carry the vulnerable driver if their kernel configuration included the drm/msm driver and used a kernel revision prior to the upstream fix. Examples of Microsoft projects that ship or build Linux kernels include:
- Azure Linux images (explicitly confirmed by Microsoft).
- The WSL2 kernel (Windows Subsystem for Linux ships a Microsoft‑maintained Linux kernel binary for WSL2).
- Special Microsoft IoT/embedded offerings historically based on Linux (where Microsoft may produce appliance images).
- Any Microsoft internal test images, device firmware or partner builds that incorporate a Linux kernel.
- The practical exposure depends on platform and kernel configuration:
- The Qualcomm MSM DRM driver targets Qualcomm SoCs (mobile/embedded ARM hardware). Most x86_64 server and desktop kernels do not enable Qualcomm SoC driver sets by default; cloud x86_64 images typically omit mobile SoC drivers. Consequently, many Azure VM images and Microsoft’s WSL kernels for x86_64 likely do not include drm/msm modules in runtime configurations — which means they would not be affected even if the upstream kernel revision once contained the code.
- Conversely, any Microsoft product that produces kernel images for ARM platforms (or publishes broad kernels that enable many drivers) could include the drm/msm code. That is why Microsoft’s advisory is careful to name the specific product they have validated and to promise updates if other products are discovered to include the vulnerable component.
- Public vulnerability trackers and Linux distribution advisories treat this as a Linux kernel issue — distribution and device vendors are the primary parties that will map the fix into their own binaries. Independent trackers (NVD, Debian security tracker) record the kernel commit and which kernel versions are affected; they do not track Microsoft‑product mappings in detail, so vendor confirmation (Microsoft in this case) is the authoritative product mapping.
How to verify whether a Microsoft product or image includes drm/msm (practical steps)
If you need to confirm whether any Microsoft product image you manage ships the vulnerable driver, perform these checks (applies to Azure images, WSL kernels, appliance images, and custom Microsoft‑provided kernels):
- Identify the kernel binary shipped with the product:
- For cloud VM images: inspect the kernel package and the running kernel (uname -a).
- For WSL2: check the shipped kernel binary version and configuration (the WSL kernel source or its published change log).
- For appliance/embedded images: extract the kernel or initramfs and examine contents.
- Check whether drm/msm exists in the kernel image or modules:
- List installed modules (on a running image): lsmod | grep msm
- Search module directory: find /lib/modules/$(uname -r) -type f -name 'msm' -print
- Inspect kernel config for driver selection: zgrep MSM /boot/config-$(uname -r) or grep -i 'CONFIG_DRM_MSM' /lib/modules/$(uname -r)/build/.config
- Verify the kernel version and upstream commit mapping:
- Compare uname -r against the kernel stable branches and the upstream commit ranges for CVE‑2025‑39747 (trackers list the stable commit IDs that contain the fix).
- Look for the presence of the specific upstream commit IDs or the fix lines in the tree (inspect /proc/version or the vendor changelog). NVD and distribution trackers list the commit references the fix was merged into.
- If you cannot boot an image:
- Mount the image’s filesystem and inspect /lib/modules for msm drivers and /boot/config* for ACC flags.
- For kernel packages, check package changelogs for the upstream commit ID that implements the krealloc error check.
- When in doubt, consult vendor advisories and the product security page:
- Microsoft’s Security Response Guide (MSRC) is the authoritative statement for Microsoft products; Microsoft has explicitly named Azure Linux and promised to update the CVE if more products are affected.
Practical risk model — who should care most
- Any environment that runs kernels built for Qualcomm SoC hardware or wide‑configuration kernels that include the drm/msm driver should prioritize validation and patching.
- Multi‑tenant cloud hosts and systems that could expose device nodes (/dev/dri/*) to unprivileged users or containers are higher risk for local Denial‑of‑Service if the driver is present.
- Embedded devices and vendor forks (Android OEM kernels, SoC vendor kernels) commonly include MSM DRM code for Qualcomm hardware and represent the longest tail of vulnerable devices. Distributors and device OEMs are typically the slowest to backport fixes, so embedded fleets are the key long‑tail concern.
For most standard Microsoft cloud workloads on x86_64 servers, practical exposure is often low because the Qualcomm MSM DRM driver is targeted at mobile SoCs. That explains why Microsoft’s immediate mapping identifies Azure Linux (their kernel image inventory) rather than, say, WSL for Windows on typical x86 machines. However,
any Microsoft product that intentionally ships kernels for ARM/Qualcomm platforms or uses a broad kernel configuration could also be affected — hence Microsoft’s conservative phrasing and commitment to update the CVE mapping if more products are identified.
Recommended actions for administrators and security teams
- Confirm Microsoft’s advisory status for the product(s) you run. Microsoft’s guidance naming Azure Linux is the canonical current mapping for Microsoft products; check MSRC product pages and CSAF/VEX feeds for updates.
- Inventory kernels and modules across your estate:
- Run the module and config checks described above (lsmod, find under /lib/modules, zgrep CONFIG_DRM_MSM).
- Where possible, check package changelogs for the upstream commit that fixes krealloc handling.
- Patch promptly if your kernel includes drm/msm and the kernel revision predates the fix:
- Install the vendor or distribution kernel update that contains the upstream fix.
- For custom kernels, cherry‑pick the upstream stable commit(s) that implement the krealloc error check and rebuild your kernel.
- Reboot affected hosts to ensure the new kernel is running.
- Apply compensating controls if you cannot patch immediately:
- Restrict access to DRM device nodes (/dev/dri/*) so that only trusted accounts or groups can interact with them.
- Avoid exposing DRM devices into untrusted containers (do not mount device nodes unless necessary).
- Increase monitoring for kernel oops traces referencing drm/msm call frames and problematic function names.
- For vendors and device fleets:
- Prioritize backporting the upstream fix into SoC‑specific kernels and provide customers an update path (OTA or manual).
- Communicate timelines clearly for long‑tail devices that will receive the patch.
Why Microsoft’s “Azure Linux only” wording is responsible but limited
Microsoft’s statement that “Azure Linux is the Microsoft product that includes this open‑source library” is a snapshot of Microsoft’s product mapping efforts. It is a responsible and transparent disclosure practice: identify the Microsoft product(s) you have found that ship the vulnerable code and promise to update the mapping if additional Microsoft products are discovered.
However, that language cannot be taken as an exhaustive inventory of all existing Microsoft binaries across every internal, embedded, partner, or test image. The underlying technical reality — the drm/msm code is upstream Linux kernel code used by vendors building kernels for Qualcomm hardware — means other Microsoft kernel images or partner devices could theoretically include it. That is why Microsoft explicitly commits to updating the CVE if they find additional impact. Treat the Microsoft statement as the authoritative current mapping, but also run the verification steps above for any Microsoft image you operate or support.
Verification notes and cross‑checks
- Public vulnerability databases (NVD and distribution security trackers) identify the CVE as a Linux kernel issue and provide the upstream commit references and affected kernel ranges. Those independent trackers confirm the technical scope of the fix (krealloc error handling in drm/msm).
- Microsoft’s advisory stating Azure Linux is the Microsoft product currently identified as including the vulnerable code is the vendor‑level product mapping; it is the authoritative Microsoft position until they publish an update saying otherwise.
- The Qualcomm MSM DRM driver is maintained under the ARM/Qualcomm driver area in the Linux kernel, which explains the driver’s hardware focus and why x86_64 server kernels often do not enable it. That hardware specificity underpins the practical exposure model and why many mainstream Microsoft products (x86 cloud images, standard WSL kernels) will not be affected in practice, while ARM/SoC targeted images could be.
If any claim about “other Microsoft products” cannot be verified by Microsoft public advisories or by direct inspection of the product’s kernel, treat those claims as
unverified and follow the verification steps above. When a vendor publishes a product mapping (as Microsoft did), use that mapping as the current authoritative source, and expect it to be updated if product inventories reveal further coverage.
Conclusion
- Microsoft’s advisory correctly and transparently identifies Azure Linux as the Microsoft product that currently includes the open‑source component containing the bug; they state they will update the CVE entry if additional Microsoft products are found to be impacted. That makes Azure Linux the only Microsoft product currently listed by Microsoft as including the vulnerable code, but it is not a proof that no other Microsoft product could contain the same upstream kernel driver.
- The vulnerability is an upstream Linux kernel issue (drm/msm) that primarily affects Qualcomm SoC driver stacks; practical exposure depends on whether a given kernel build includes the msm driver and is running on compatible hardware. Independent trackers (NVD, Debian security tracker) document the fix and affected kernel ranges.
- Administrators should verify kernel module presence in any Microsoft kernels they operate, apply vendor patches or upstream commits promptly where needed, and apply temporary mitigations (device access controls and monitoring) until affected kernels have been replaced.
Verified references used in the cross‑check and technical validation include multiple independent vulnerability trackers and kernel maintainer documentation, and Microsoft’s own advisory mapping for Azure Linux.
Source: MSRC
Security Update Guide - Microsoft Security Response Center