CVE-2025-38585: Azure Linux attestation and checking Microsoft kernel artifacts

Short answer — No, not necessarily.

• Microsoft’s update guide explicitly states that “Azure Linux includes this open‑source library and is therefore potentially affected” and that Microsoft will expand product mappings (CSAF/VEX) if other Microsoft products are later found to ship the same upstream component. That wording is an authoritative attestation for Azure Linux today, but it is a product‑scoped inventory statement, not a technical proof that no other Microsoft artifact contains the same kernel code.

Why (technical summary, with sources)

• The bug (CVE‑2025‑38585) is in the upstream Linux kernel staging/media atomisp code (gmin_get_var_int) and was assigned/published on 19 Aug 2025. Upstream patches were committed to the kernel stable trees; distribution and vendor advisories and the NVD describe the defect and provide the kernel patch references. If a Microsoft product ships a Linux kernel (or a kernel build that includes the atomisp staging driver from an affected upstream version), that product could also be affected until patched.
• Microsoft’s attestation for Azure Linux is therefore the company saying “we found the component in that product and are treating it as potentially affected.” Microsoft also says it will update the CVE/product mapping if it finds the same component in other Microsoft products. That implies Azure Linux is the only Microsoft product Microsoft has completed and published an inventory for so far — but it does not prove exclusivity across all Microsoft‑provided kernel artifacts.

Examples of other Microsoft artifacts that could plausibly carry the same upstream code

• Microsoft publishes and ships Linux kernel sources and binary builds for some products (for example the WSL2 kernel source and builds on GitHub). Those kernel artifacts include the upstream kernel tree (drivers/…) and therefore could include the same staging drivers depending on the kernel version/configuration used. Whether any given Microsoft kernel image is actually vulnerable depends on the kernel version and configuration and whether the atomisp code is built-in or absent.

What this means for you (practical guidance)
1) Short operational decision

• Treat Microsoft’s Azure Linux attestation as authoritative and in‑scope: if you run Azure Linux images, plan to apply the Microsoft/Ubuntu/your distro kernel updates that contain the upstream fix now.

2) Don’t assume other Microsoft products are safe

• If you run other Microsoft artifacts (WSL2 kernels, linux‑azure kernels, Marketplace images, appliance images Microsoft distributes, device/IoT images, etc., do not assume they are unaffected simply because they are not named in the Azure Linux VEX entry. Inventory and verify each artifact (see checks below). Microsoft will update its attestations if it identifies additional affected products, but the absence of an attestation is not positive proof of absence.

3) How to check whether a given system / image is likely affected

• Check the kernel version and compare to the upstream vulnerable ranges reported by NVD/upstream (NVD lists the upstream kernel versions/patch references). Example quick checks:
• uname -r # to get running kernel version.
• Compare the kernel version to the NVD/patch ranges (the NVD entry lists the affected upstream ranges and links to the kernel.org commits).
• Check whether atomisp (staging) is present in your kernel build:
• On a running Linux system:
• grep -i atomisp /lib/modules/$(uname -r) -R || modinfo atomisp (may show module or not)
• grep -i gmin_get_var_int /lib/modules/$(uname -r) -R (search for symbols or source installed with modules)
• zcat /proc/config.gz | grep -i atomisp (if /proc/config.gz is present)
• ls /sys/module | grep -i atomisp
• On images (offline):
• Inspect /boot/config-<version> or the kernel config used to build the image and search the build tree for drivers/staging/media/atomisp or the symbol gmin_get_var_int.
• For WSL: open a WSL shell and run uname -r and the same module/config checks; Microsoft publishes the WSL kernel source and the WSL kernel binary’s version tags on GitHub so you can compare to upstream.

4) Recommended mitigations until patched

• Apply updates: install the vendor/distributor kernel updates (Azure Linux updates, Microsoft WSL kernel updates via Windows Update/WSL releases, distro kernel updates). Upstream kernel patches are already available; distributions and Microsoft will publish backports/updates.
• Restrict access: if you cannot immediately patch a host, restrict access to device nodes that could be used to exploit kernel drivers (example: restrict access to /dev/video* and /dev/dri or other device nodes used by camera/DRM subsystems) and avoid running untrusted code or mounting untrusted containers that might exercise the driver during initialization.
• Inventory & prioritize: prioritize images that are multi‑tenant, exposed to untrusted users, or that run on hardware families noted by the advisory (the upstream text mentions Intel Bay Trail and Cherry Trail in the atomisp use context).

5) If you use Microsoft‑supplied artifacts other than Azure Linux

• Ask Microsoft for an explicit VEX/CSAF attestation or SBOM for the specific product/artifact you run (MSRC has committed to publish CSAF/VEX attestations as inventory work completes). If you need a faster answer for a particular product, open a support ticket and request confirmation/backports for that SKU/image.

Sources (key references)

• Microsoft Security Update Guide entry for CVE‑2025‑38585 — Microsoft’s attestation text and the statement that Azure Linux includes the open‑source library and that MS will update mappings if additional products are found.
• NVD (CVE‑2025‑38585) — description, publication date (19 Aug 2025) and kernel patch references (kernel.org links). Use this to determine upstream affected versions and to find the upstream commits/patches.
• Patchew / kernel patch summary — shows the patch discussion and the defect summary for the atomisp change.
• Ubuntu / other distro advisories — for distribution‑level fixes and how they will be shipped to customers; check your distro vendor for the specific backport/patch schedule for kernels in their images.
• Microsoft WSL2 Linux kernel repo (public on GitHub) — demonstrates Microsoft ships/maintains kernel source and builds for WSL; kernels shipped by Microsoft may include or exclude drivers depending on config and version. This is a reminder that other Microsoft kernel artifacts exist and must be verified individually.

If you want, I can:

• Check a specific kernel version string (paste uname -r) and tell you whether it falls into the upstream ranges called out in the NVD entry.
• Provide a short shell script you can run to enumerate candidate images/hosts in your estate and flag those that need immediate inspection (checks kernel version, presence of atomisp/related modules, and whether device nodes exist).
• Draft a short request you can send to Microsoft Support asking for a VEX/SBOM attestation for a particular Microsoft product image/SKU.

Which of the above would you like me to do next?

---

Source: MSRC Security Update Guide - Microsoft Security Response Center