CVE-2025-40001: Linux mvsas UAF fix and Azure Linux Attestations

A recently disclosed Linux-kernel flaw, tracked as CVE-2025-40001, fixes use-after-free (UAF) bugs in the mvsas SCSI driver by changing how delayed work is cancelled during device detach; Microsoft’s public advisory names the Azure Linux distribution as a known product that includes the upstream component and will expand its machine‑readable attestations if further Microsoft artifacts are found to ship the same code.

Background / Overview​

The vulnerability, reported in mid‑October 2025 and documented in multiple vendor trackers, is a race condition in the Marvell/Marvell‑derived SCSI driver commonly known in Linux source trees as mvsas. During device removal the driver originally called cancel_delayed_work, which can fail to cancel a work item that is already running; if the driver frees the mvs_info structure while the delayed worker is still executing, the worker may dereference freed memory — a classic use‑after‑free. The upstream remedy replaced cancel_delayed_work with cancel_delayed_work_sync (or otherwise ensured active work completes before deallocation) to prevent the window that allows the UAF. This is a kernel‑level memory‑corruption issue discovered via static analysis and fixed upstream in the stable kernel trees. The vulnerability is local (an attacker requires the ability to trigger operations on the affected controller), not a remote network‑only exploit in its basic description, and many downstream distributions have issued advisories or backported fixes. The variant and the scoring reported in vendor trackers place the finding at an elevated severity for systems that run the vulnerable driver and permit local untrusted code to interact with the controller.

---

What Microsoft said — reading the advisory​

Microsoft’s Security Response Center (MSRC) entry for CVE‑2025‑40001 answers a frequently asked question: is Azure Linux the only Microsoft product that includes the vulnerable open‑source component? Microsoft’s public response states that the Azure Linux distribution (the company’s Linux distro image) does include the upstream library/driver in question and is the product Microsoft has inventoried and attested so far; it also explains Microsoft’s phased rollout of machine‑readable CSAF/VEX attestations (started October 2025) and commits to updating CVE product coverage if additional Microsoft products are later found to include the same upstream code. That wording is an inventory attestation for Azure Linux, not a definitive technical guarantee that no other Microsoft artifact contains the vulnerable code.

Plain‑English interpretation​

• Microsoft has completed an inventory for Azure Linux and confirmed the upstream mvsas code is present there.
• Microsoft has not said other Microsoft products are unaffected — only that it has not (yet) attested them as containing the upstream component. Microsoft will update CVE/product attestations if additional Microsoft products are found to ship the component.

---

Is Azure Linux the only Microsoft product that includes the component?​

Short answer: No — Azure Linux is not necessarily the only Microsoft product that may include the vulnerable code. The vendor attestation covers Azure Linux because that product was inventoried first. However, other Microsoft‑maintained artifacts — most notably the Windows Subsystem for Linux (WSL) kernel and other Microsoft‑distributed kernel builds — plausibly include the mvsas driver, and therefore they could be in scope if their kernel configuration or module set enables it.
Evidence and independent corroboration:

• The official WSL kernel sources and community kernel configurations used for WSL builds show SCSI and many vendor controller drivers compiled as modules, and third‑party config dumps derived from WSL kernel builds include CONFIG_SCSI_MVSAS set to “m” (module). That indicates the driver is present in typical WSL kernel configurations.
• The upstream CVE description, kernel commits, and distribution trackers show the issue is in the standard mvsas code path in the Linux kernel — a component that many kernel builds include unless explicitly disabled. That makes it plausible for any Microsoft product shipping a Linux kernel (or shipping a distribution image) to include the same code unless Microsoft’s per‑product inventory explicitly marks it NotAffected.

Why the distinction matters​

Microsoft’s CSAF/VEX release model intentionally begins with one product (Azure Linux) to ensure high‑quality, machine‑readable attestations. The absence of a VEX attestation for another Microsoft product is not the same as a vendor statement that the product is safe. Until the vendor has completed an artifact‑level inventory for that product, organizations must perform their own checks or treat those artifacts as “requires verification.”

---

Technical analysis: attack surface and exploitation scenarios​

The mvsas driver controls Marvell SAS/SATA controllers. Practical exploitation requires local access and the ability to interact with the controller or trigger device detach/driver removal behavior. Typical realistic scenarios include:

• Systems with local untrusted workloads able to trigger SCSI driver operations (e.g., shared hosting or untrusted containers with access to device nodes).
• Misconfigured multi‑tenant setups where an attacker can manipulate hardware or force device detach/attach cycles.
• Complex virtualization or passthrough configurations where devices are moved between hosts or VMs and the host kernel still manages the driver lifecycle.

The fixed root cause is racey cancellation of delayed work: cancel_delayed_work returns before a running delayed worker completes, allowing the deallocation of driver structures while the worker is still accessing them. Upstream replaced the caller with a synchronous cancel (or equivalent synchronization) to guarantee the worker finishes before resources are freed. The fix is straightforward from a code correctness point of view, but until a patched kernel is deployed the race remains exploitable in theory.

Real‑world exploitability​

Most public tracking pages list this as not remotely exploitable without prior local access and with non‑trivial prerequisites. That lowers the immediate blast radius compared with remote, unauthenticated kernel flaws, but in hostile multi‑tenant environments or where local code execution is easy to obtain (e.g., compromised user accounts, containers with access to device nodes), the risk is material and should not be ignored. AWS/ALAS and other distro trackers that scored the issue reflect this local‑access vector and give a moderate‑to‑high impact score for confidentiality/integrity/availability on affected hosts.

---

Which Microsoft artifacts should you check right now​

• Azure Linux images and kernels — Microsoft has attested these as Known Affected (or under investigation) for the upstream component; apply the vendor’s recommended updates.
• Windows Subsystem for Linux (WSL) kernels — Microsoft ships a WSL‑specific Linux kernel and also allows custom kernels; check whether installed WSL kernels expose or build the mvsas driver as a module. Many community and WSL config files show CONFIG_SCSI_MVSAS enabled as a module. If you run WSL with the Microsoft kernel, verify whether your current WSL kernel build includes the driver and whether a patched WSL kernel update is available.
• Azure Marketplace images and Microsoft‑provided VM images that include Linux kernels — inventory kernel config and module sets inside your VM images. Microsoft’s VEX attestation will expand gradually; don’t wait if you have high‑value, multi‑tenant, or security‑sensitive workloads.
• Any Microsoft appliance or service that embeds a Linux kernel (CI/CD runners, edge images, specialized appliances) — perform per‑artifact checks until Microsoft’s VEX/CSAF attestation covers the product.

---

Practical detection and verification steps​

Use the following per‑host checks to determine whether the kernel or image in your environment has the mvsas driver enabled or loaded:

• Check whether driver module is loaded:
• lsmod | grep mvsas
• Check module availability in modules directory:
• find /lib/modules/$(uname -r) -name 'mvsas' -print
• Inspect the running kernel config (if available):
• zgrep CONFIG_SCSI_MVSAS /proc/config.gz
• grep CONFIG_SCSI_MVSAS /boot/config-$(uname -r)
• Ask the kernel what the module provides:
• modinfo mvsas

If the module is present but not loaded, you still need to treat the system as potentially vulnerable because the module can be loaded later. If it’s loaded, the host is in scope and the vendor remediation path should be applied. If you use WSL, check the WSL kernel version and modules via the guest distro (or update WSL itself — see the recommended steps below).

---

Immediate mitigations and remediation​

Apply patches as the primary remediation. Vendor and distribution trackers (Ubuntu, SUSE, Amazon Linux, etc. have issued advisories and packages; apply them promptly to affected hosts. Upstream fix is simple and well understood: ensure delayed work is cancelled synchronously or otherwise synchronized to avoid freeing structures while work runs. If immediate patching is impossible, consider temporary mitigations:

• Blacklist or unload the mvsas module on systems where SAS controllers are not in use:
• echo "blacklist mvsas" > /etc/modprobe.d/blacklist-mvsas.conf
• update-initramfs -u (or distro equivalent) and reboot
• Warning: blacklisting the module will disable any attached Marvell SAS/SATA controllers that require that driver. Only use this when it is safe to do so.
• Restrict access to host device nodes that map to SAS/SATA controllers. Remove or tighten permissions for /dev/ nodes and avoid mounting raw device nodes into untrusted containers.
• For WSL instances: update the WSL kernel provided by Microsoft or switch to a patched custom kernel (if you maintain and trust your own WSL kernel builds). On Windows hosts, the wsl command provides update features; keep WSL and Windows system updates current.

---

How to patch Microsoft‑supplied artifacts (practical guidance)​

• Azure Linux (Microsoft guidance): apply the Azure Linux kernel updates and distribution package updates Microsoft publishes for the CVE. Use your standard package management and image update workflows for Azure VMs. Microsoft’s VEX/CSAF artifacts will list KnownAffected and Fixed statuses per product as they complete inventory.
• WSL: run Windows Update (which delivers WSL kernel updates in many builds) or run:
• wsl --update
• wsl --shutdown
• Then restart the WSL distro and verify uname -r inside the distro.
  If you run a custom WSL kernel, rebuild using the upstream fix or use Microsoft’s updated kernel. Check the Microsoft WSL GitHub repository and official docs for the recommended kernel configuration and release notes.
• Generic Linux images on Azure Marketplace: use the distro vendor’s kernel packages (Ubuntu, RHEL, SUSE, Amazon Linux) and apply vendor patch bundles or kernel upgrades. If you rely on Microsoft images that bundle a kernel, inspect the kernel version and module list and follow the vendor or Microsoft guidance for patching.

---

Operational checklist (short, prioritized)​

• Inventory: identify hosts and images that include the mvsas driver (module presence, kernel config, package list).
• Patch: apply vendor patches (Azure Linux first for Microsoft‑attested coverage), then patch WSL hosts and other Microsoft images as applicable.
• Mitigate: where patching is delayed, blacklist or unload the module on safe systems and restrict device node access. Warn about functionality loss.
• Monitor: watch kernel logs (dmesg) and your EDR for crashes, kernel oopses, or suspicious module loads that coincide with untrusted processes.
• Automate: ingest Microsoft’s CSAF/VEX artifacts into your vulnerability management pipeline so product‑level attestations automatically update your impacted asset lists when Microsoft extends coverage.

---

Risks, strengths and the limits of vendor attestations​

Strengths:

• The upstream fix is straightforward and already accepted into stable kernel trees. Distribution vendors and at least one major cloud vendor (Amazon Linux) have tracked the issue and published fixes or status reports. This means the patching story is clear and actionable for most operators.
• Microsoft’s move to publish CSAF/VEX attestations for Azure Linux increases transparency and makes automated inventory alignment possible for customers who consume those machine‑readable artifacts. That reduces false positives and shortens triage cycles.

Risks and limitations:

• Microsoft’s statement that Azure Linux includes the open‑source library reflects completed inventory for that product only. It is not a comprehensive denial of presence in other Microsoft artifacts. Treat absent attestations as “not yet inventoried” rather than “not affected.”
• Kernel drivers compiled as modules can be shipped in many build artifacts even when not used by a given workload. Presence of a module file in an image means the code exists and could be loaded later, which keeps the host in scope for vulnerability management even if the module isn’t currently loaded.
• Environments with multi‑tenancy, hardware pass‑through, or untrusted local workloads (containers with device access, hosted CI systems, etc. remain most at risk. The UAF requires local manipulation of the driver lifecycle, so purely remote stacks without local access are less exposed — but the risk changes in mixed‑trust or shared hardware contexts.

---

Conclusion and recommended actions​

Microsoft’s advisory correctly identifies Azure Linux as a product that includes the upstream mvsas code and will expand attestations as inventory work completes. That attestation is an authoritative statement for Azure Linux, but it should not be read as a universal guarantee that no other Microsoft product ships the same upstream driver. Practical evidence — including standard WSL kernel configurations and community dumps showing CONFIG_SCSI_MVSAS enabled as a module — makes it plausible that other Microsoft‑supplied kernel artifacts (WSL and some Marketplace images) could include the vulnerable driver. Customers should therefore:

• Treat Azure Linux hosts as in‑scope and apply Microsoft’s recommended updates immediately.
• Inventory other Microsoft artifacts you consume (WSL kernels, Marketplace images, custom images) for presence of the mvsas driver and patch them or apply mitigations if necessary.
• Ingest Microsoft’s CSAF/VEX attestations into your automation so that when Microsoft expands its product coverage you receive updates automatically.

This approach — vendor patching for attested products, artifact‑level verification for everything else, and short‑term mitigations where immediate patching is not possible — gives a defensible, pragmatic path to reduce operational risk while Microsoft completes its per‑product inventory and publishes further VEX/CSAF attestations.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center