CVE-2025-40096: Azure Linux DRM Scheduler Double Free and MSRC Attestation

A recently assigned Linux-kernel CVE — CVE-2025-40096 — discloses a memory-management defect in the kernel DRM scheduler (drm/sched) that can produce a double free when dependency handling fails, and Microsoft’s Security Response Center (MSRC) has published a product-level attestation stating that Azure Linux includes the implicated open‑source component and is therefore potentially affected. That attestation is authoritative for Azure Linux images, but it is not a categorical guarantee that no other Microsoft product includes the upstream kernel code; artifact-level verification is required to determine exposure across WSL, linux-azure kernels, Marketplace images, and other Microsoft-supplied artifacts.

Background / Overview​

CVE-2025-40096 is a Linux-kernel robustness bug fixed in the DRM scheduler. The problem arises when drm_sched_job_add_dependency consumes a reference to a dma_fence both on success and on failure; a follow-up dma_fence_put on the error path can therefore release the same reference twice, producing a double free. The flaw appears to trace back through several historical commits in the drm/sched code and was inserted when dependency tracking was introduced; it was corrected and merged into the kernel stable trees in late October 2025. The public vulnerability databases and major distributions catalog the CVE and list the upstream fixes and backports. Why this matters operationally: double frees in kernel space are classed as memory corruption defects. In many cases they manifest as kernel oopses or crashes (availability impact), and depending on the memory allocator, surrounding code, and mitigations present (KASLR, SMEP/SMEP, memory tagging), they can — in theory — be escalated into more serious integrity or confidentiality impacts. Public reporting for CVE-2025-40096 frames this as a robustness/availability issue that should be fixed promptly, and distributions have been shipping stable backports.

---

What Microsoft actually said — and what it means for customers​

Microsoft’s MSRC entry for the CVE includes the line quoted in the user’s question: “Azure Linux includes this open‑source library and is therefore potentially affected.” That language is framed inside Microsoft’s new CSAF/VEX attestation approach: Microsoft began publishing machine‑readable VEX attestations starting with the Azure Linux distribution in October 2025 as part of a phased rollout intended to improve transparency about which third‑party CVEs affect which Microsoft products. The blog announcing that program makes the intent explicit: start with Azure Linux, publish deterministic attestations, and expand coverage to additional product families over time. Operational interpretation of Microsoft’s statement:

• Authoritative for Azure Linux: If you run Microsoft‑published Azure Linux images (the Azure Linux distribution / linux-azure images), treat Microsoft’s VEX/CSAF output for Azure Linux as the canonical signal for that product family and act on Microsoft’s remediation guidance.
• Not a universal exclusion for other Microsoft products: The attestation documents what Microsoft has validated so far — not a proof that other Microsoft artifacts are free from the same upstream code. Absence of a product name in Microsoft’s VEX output is absence of attestation, not proof of absence. Other Microsoft-supplied kernels or images may still include the vulnerable drm/sched code depending on build decisions.
• Microsoft will update the CVE mapping if it discovers additional impacted products. That is a commitment to expand the VEX coverage as inventory work completes.

These three points are crucial for security teams: the MSRC note reduces uncertainty for Azure Linux customers but leaves the onus of verification on operators who run other Microsoft artifacts (for example, the WSL2 kernel, marketplace VM images, or custom Microsoft builds).

---

Technical anatomy: what CVE-2025-40096 actually fixes​

Where the bug lives​

• Affected subsystem: drm/sched (the DRM scheduler code path used by GPU drivers and fence/dependency management).
• Root cause: logic error in dependency handling where reference ownership is ambiguous on error paths — a call that consumes a reference can cause the caller to also release that reference on its own error-handling path, producing a double free.
• Typical observable symptom: kernel oopses, crashes, or other stability failures when the affected driver schedules work and dependency handling hits the failure branch.

Fix and provenance​

The fix is small and defensive: adjust the reference ownership semantics so that the function that successfully takes a reference is the only code responsible for releasing it, or ensure the caller does not attempt to release a reference already consumed. The patch was merged into the kernel stable tree (6.1-stable and others) in late October 2025; maintainers flagged it for backporting where appropriate. Kernel mailing-list notices and stable-tree commits show the patch placement and the maintainer discussion.

---

Is Azure Linux the only Microsoft product that includes the open-source library and is therefore potentially affected?​

Short, precise answer: No — Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the vulnerable kernel component, but that attestation is product‑scoped and does not prove exclusivity. Other Microsoft artifacts that ship a Linux kernel build can in principle include the same upstream code depending on kernel version, configuration, or backport history. For that reason, you must verify on a per‑artifact basis whether a given Microsoft product includes the drm/sched code and uses a vulnerable kernel revision.
Why that nuance exists:

• Kernel code is an artifact-level property. Two kernels built from the same source can differ dramatically based on CONFIG_* options. A kernel with drm/sched compiled in (or carried as a module) will expose the vulnerability; a kernel built without drm/sched or with the fix backported will not.
• Microsoft ships multiple Linux‑based artifacts that are plausible carriers:
• Azure Linux / linux-azure images (attested by MSRC).
• WSL2 kernel builds — Microsoft publishes and manages the WSL2 kernel source and binary; a WSL2 kernel built with an affected drm/sched revision could, in principle, include the vulnerable code.
• Marketplace images, appliance/firmware images, or custom Microsoft kernels — some Marketplace or partner images include kernels Microsoft or partners maintain; these must be verified individually.
• Microsoft’s public statements commit to updating the CVE/VEX mapping if more products are discovered to ship the code — which implies the inventory is ongoing and phased, not exhaustive at publication time.

---

Practical verification checklist (what to do now)​

Security and operations teams should treat Microsoft’s Azure Linux attestation as a confirmed hit for Azure Linux images and use it to accelerate remediation. For any other Microsoft artifact, follow these steps to verify exposure and remediate if necessary.

1. Inventory and identify Microsoft-supplied Linux artifacts​

• Enumerate all Microsoft-supplied Linux kernels you run: Azure VM images, linux-azure kernel packages, WSL2 kernels, Marketplace VM images, managed node images (e.g., AKS node images), and any Microsoft-published appliance images.
• Use SBOMs/VEX outputs when available; Microsoft’s CSAF/VEX files for Azure Linux are machine‑readable and intended for automation. Where a VEX attestation exists, consume it directly.

2. Verify kernel configuration or module presence​

• Check whether drm/sched or related DRM scheduler code is in the kernel binary:
• Inspect /proc/config.gz (if present) or the kernel config in the distribution package.
• Look for CONFIG_DRM, CONFIG_DRM_SCHED, and other DRM-related options.
• If you can access the package metadata, check the kernel package version and distribution advisory mapping against vendor CVE lists (Ubuntu, Debian, SUSE, etc..

3. Check kernel version and applied stable backports​

• Kernel version alone is not sufficient — verify whether the upstream stable fix for CVE-2025-40096 has been applied or backported into your shipped kernel. Distribution advisories (Ubuntu, Debian, SUSE) list which package releases include the fix.

4. If exposed, apply mitigations​

• Priority remediation: install the vendor-provided patched kernel (or backported stable patch) as soon as practical.
• Short-term mitigations:
• Restrict access to DRM device nodes (/dev/dri/*) to trusted users to reduce local attack surface.
• In multi-tenant cloud environments, restrict who can run unprivileged workloads that exercise GPU/drm paths.
• Preserve logs and crash dumps for incident triage if you’ve observed recent kernel oopses that might correlate to the CVE.

5. For WSL2 or developer machines​

• Check the WSL2 kernel binary version and the WSL2 repo if you maintain custom WSL kernels. Microsoft publishes the WSL2 kernel source; verify whether the build used by your Windows installation contains a vulnerable drm/sched revision.

6. Maintain a feed-forward process​

• Subscribe to vendor CVE pages (MSRC VEX/CSAF feeds for Azure Linux), and monitor distro trackers (NVD, Debian/Ubuntu/SUSE advisories) for confirmations of backport and package availability.

---

Detection and forensic guidance​

• Kernel oops and stack traces that reference drm_sched or dma_fence routines should be treated as high-priority evidence. Capture the oops messages and correlate them to the kernel build ID (uname -a; cat /proc/kallsyms when safe).
• If you operate GPU-accelerated workloads (containerized inference, ML workloads, graphics workloads), prioritize patching nodes that expose /dev/dri or that load DRM modules.
• For cloud customers: if your VM images are from Microsoft (Azure Marketplace), do not assume non-Azure-Linux Marketplace images are covered by Microsoft’s Azure Linux VEX attestation — verify per image owner and per image kernel package. Microsoft explicitly states marketplace images published by third parties remain the publisher’s responsibility.

---

Vendor messaging and transparency: strengths and caveats​

Microsoft’s move to publish machine-readable CSAF/VEX attestations is a major positive step and aligns with industry trends toward automated, verifiable supply-chain vulnerability signals. The benefits include:

• Deterministic automation: VEX files let security teams automate decision-making and triage for the attested product family.
• Faster triage for Azure Linux customers: Microsoft’s attestation removes guesswork for that product family and reduces false positives for Azure Linux images.

However, there are caveats and operational risks security teams must understand:

• Phased coverage creates interim ambiguity. Starting with a single product family (Azure Linux) means other Microsoft artifacts remain un‑attested until the inventory work completes. That leaves a window where customers must rely on artifact inspection rather than vendor attestation.
• Artifact-level variance in kernels. Even within a single vendor, different kernels can include different drivers and different backports; scanning commitments reduce uncertainty only when they cover the artifacts you run.
• Operator burden increases for mixed environments. Organizations that run a mix of Azure Linux, WSL2, Microsoft marketplace images, and custom kernels must implement an inspection pipeline to confirm whether each artifact includes drm/sched or the fixed commit.

---

Risk assessment: who should care most and why​

• Cloud VM operators on Azure running Azure Linux — highest priority: Microsoft has attested these images as potentially affected and will supply VEX records and patches. Treat Azure Linux images listed in Microsoft’s VEX feed as in-scope and apply updates.
• Clusters and multi-tenant hosts with GPU workloads — elevated priority: crash-inducing kernel defects in DRM scheduler code can produce disruptive host instability across tenants, making timely patches essential.
• Windows users of WSL2 — moderate priority: WSL2 uses a Microsoft-supplied kernel binary; verify whether your WSL2 kernel is built with the affected drm/sched and whether Microsoft has published a WSL2 update or advisory.
• Enterprise desktops without GPU/DRM access — lower immediate priority: if the desktop kernel does not include DRM drivers or if /dev/dri is not accessible, practical exposure is reduced; still, vendors and distro trackers recommend applying patches as available.

---

What we verified and cross‑checked​

• The technical description of CVE-2025-40096 (double free in drm/sched) was verified against multiple independent sources: the NVD CVE entry and multiple distribution trackers (Ubuntu, Debian, SUSE) and kernel mailing-list notices confirming the stable-tree merge. These sources are consistent in describing the defect as a double free in drm_sched_job_add_resv_dependencies and in documenting the upstream fixes.
• Microsoft’s product attestation (Azure Linux includes the open-source library and is therefore potentially affected) and its VEX rollout timeline were verified against Microsoft’s MSRC blog post announcing CSAF/VEX for Azure Linux in October 2025. That blog explicitly states the phased approach and the plan to expand attestations beyond Azure Linux over time.
• The practical operational guidance (inventory, check kernel config, apply patched kernels) is consistent with upstream distro advisories and best-practice remediation steps documented by vendors and tracking databases.

If you see a claim about “only Azure Linux is affected” treated as definitive, flag that as a misreading of Microsoft’s attestation model: Microsoft has attested only Azure Linux so far; it has not scanned and declared all Microsoft artifacts unaffected. That is an important distinction for defenders and for automation that consumes VEX/CSAF outputs.

---

Recommended timeline and priorities for patching​

• Immediately: consume Microsoft’s Azure Linux VEX/CSAF feed and mark all Azure Linux images as in‑scope. Prioritize patching Azure Linux VMs and node images.
• Within 24–72 hours: inventory WSL2 kernels, marketplace images, and other Microsoft-supplied artifacts in your estate; verify kernel configs and whether drm/sched is present.
• Within 1–2 weeks: deploy vendor-published patched kernel packages where available; if you manage appliance or custom kernels, engage vendors for backports or build the upstream stable patch into your build pipeline.
• Ongoing: subscribe to VEX/CSAF feeds and vendor advisories to detect when Microsoft expands its attestations beyond Azure Linux; automate triage where feasible.

---

Final analysis — strengths, risks, and the path forward​

Microsoft’s public attestation that Azure Linux includes the open‑source library and is therefore potentially affected is an important operational signal: it gives Azure Linux customers a machine‑readable, vendor-backed reason to prioritize remediation. The introduction of CSAF/VEX for Azure Linux is a meaningful transparency improvement and will help reduce false positives and speed decisions for customers who consume those feeds. At the same time, the attestation model exposes two operational gaps that organisations must address:

• Inventory blind spots. Until Microsoft completes VEX coverage across its full product portfolio, operators must perform artifact-level verification for other Microsoft-supplied kernels (WSL2, linux-azure variants, Marketplace images).
• Per-artifact kernel variance. Because kernel configuration and backporting are per-artifact choices, a simple product-level claim cannot substitute for host- or image-level confirmation.

The practical conclusion for defenders: treat Microsoft’s Azure Linux attestation as authoritative and actionable for Azure Linux, but perform and automate per-artifact verification for any other Microsoft-supplied or third‑party images you run. Patch promptly where the fix is available, restrict unnecessary access to DRM device nodes as a short-term control, and preserve crash logs for triage. Multiple independent trackers (NVD, Ubuntu, SUSE, Debian) and the kernel maintainers corroborate the technical description of CVE-2025-40096 and the remediation approach; use them to confirm whether your kernel packages already include the fix.

---

CVE-2025-40096 is a textbook example of how upstream kernel defects, vendor attestations, and phased transparency programs intersect in real-world security operations: vendor attestations speed remediation for the attested product family but do not eliminate the need for careful inventory, artifact inspection, and fast patching across a heterogeneous estate.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center