CVE-2025-37861: Linux mpi3mr Driver Fix and Azure Linux Attestation

The Linux kernel defect tracked as CVE-2025-37861 — a race in the SCSI mpi3mr driver where the task‑management (tm) thread can access an invalid reply‑queue ID while a reset thread is in progress — has been fixed upstream, and Microsoft’s public advisory confirms that Azure Linux images include the affected open‑source component and are therefore potentially affected, but that statement is an attestation of scope for Azure Linux only and should not be read as proof that no other Microsoft product could include the same vulnerable code.

Background / Overview​

CVE‑2025‑37861 is a Linux kernel bug in the Broadcom/LSI MPI3 SCSI driver (mpi3mr). The defect arises when the task‑management thread processes reply queues at the same time the reset thread is resetting those queues; the reset thread can write a sentinel queue ID (0xFFFF) that the tm thread later dereferences and which points at unallocated memory, causing a kernel crash or controller unrecoverable condition. Upstream maintainers fixed the root cause by adding a synchronization flag (io_admin_reset_sync) so the reset handler blocks I/O/admin threads during resets and waits for outstanding processing to finish. The patch was merged into the stable trees. Independent vulnerability trackers and vendor advisories report similar technical details and assign the issue a medium‑to‑high impact on availability depending on CVSS interpretation. The practical impact reported by distributors is primarily availability (kernel oops/crash, controller unrecoverable) and depends on local access to the SCSI device interfaces or workloads that interact with the affected controller.

What Microsoft actually said — and how to read it​

Microsoft’s Security Response Center (MSRC) entry for this CVE includes the product‑scoped wording you quoted: Azure Linux “includes this open‑source library and is therefore potentially affected,” and Microsoft added that it began publishing CSAF/VEX machine‑readable attestations for Azure Linux in October 2025 and will “update the CVE to reflect” any impact to additional products if further carriers are identified. That wording is a deliberate, narrow attestation of Microsoft’s inventory work for the Azure Linux family — it confirms Microsoft has validated Azure Linux images as containing the implicated component and has published VEX/CSAF data for those images.
Two important interpretive points follow from Microsoft’s phrasing:

• The statement is an affirmative attestation for Azure Linux only — it tells customers which Microsoft product Microsoft has already confirmed contains the upstream driver and therefore which images should be considered in scope for immediate triage and remediation.
• The statement is not a categorical denial that other Microsoft products are free of the component. Absence of an attestation for another Microsoft product is not proof of absence; Microsoft has committed to expand the VEX/CSAF mapping as its internal inventory identifies additional affected artifacts. Until Microsoft updates the CVE/VEX files for other SKUs, each product must be checked on a per‑artifact basis.

Short answer to the user’s question​

No — Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the affected open‑source component, but it is not technically guaranteed to be the only Microsoft product that could include that code. Other Microsoft‑distributed kernel artifacts (for example, the WSL2 kernel tree, linux‑azure kernel builds used in some VM images, Marketplace image kernels or appliance images, and any custom Microsoft‑published kernels) could carry the same upstream driver depending on build configuration and version. Until Microsoft’s inventory and VEX/CSAF attestations list those artifacts explicitly, customers should assume possible exposure and verify their own artifacts.

---

Why Azure Linux appears in Microsoft’s mapping first​

Microsoft’s CSAF/VEX rollout began with the Azure Linux family because those images are Microsoft‑built, published, and centrally managed. That makes them the easiest product family for Microsoft to inventory, attest, and update rapidly; publishing an attestation for Azure Linux provides an immediate, machine‑readable signal that Azure customers can automate against. This phased approach is standard practice among large vendors rolling out SBOM/VEX capabilities: publish attestations for the product families that are fully inventoried first, then expand as work completes.
Azure Linux being named first is therefore a pragmatic statement of fact — not a technical guarantee that no Microsoft kernel elsewhere contains the same upstream files.

Which other Microsoft artifacts could plausibly include the mpi3mr code?​

Any Microsoft product that ships a Linux kernel build or includes Linux kernel binaries is a candidate for inclusion if its kernel build configuration enabled the mpi3mr driver and the kernel revision predates the upstream fix. Practical examples:

• WSL2 kernel — Microsoft publishes the WSL2 kernel source tree on GitHub and ships compiled WSL2 kernel images to Windows clients; that repository shows the same Linux kernel trees and patch management flows Microsoft uses to build WSL kernels. Whether the distributed WSL kernel binary for a given Windows update included mpi3mr depends on that kernel’s config and release tag.
• linux‑azure / Azure kernel images — kernel packages used in Azure VM images are built separately for cloud images; if a linux‑azure kernel build included the mpi3mr driver and was built from a vulnerable commit, it would be in scope. Microsoft’s attestation process can and does map which azure kernel packages are affected.
• Azure Marketplace images and partner appliances — many Marketplace VM images embed kernel versions built by third parties or by the marketplace publisher. Microsoft’s Azure Linux attestation does not automatically cover third‑party Marketplace images; those images remain the publisher’s responsibility and must be inventoried separately.
• Custom or embedded Microsoft images — specialized appliances, IoT images, or internal images that Microsoft publishes for partners could include different kernel configs. Each artifact is a separate build decision and must be verified.

In sum: where Microsoft ships a Linux kernel, there is a plausible channel for the driver to appear. Whether it actually appears is a build‑time decision and must be checked on a per‑artifact basis.

Technical verification steps — how to check if a given host/image is affected​

For system administrators and security teams who need to confirm exposure, the following checklist provides reproducible, low‑cost checks to perform on hosts, VM images, or WSL instances.

• Identify the running kernel and package:
• uname -a
• On Debian/Ubuntu: apt changelog linux-image-$(uname -r)
• On RHEL/SUSE: rpm -q --changelog kernel-$(uname -r)
• Check whether the mpi3mr module or driver is present:
• lsmod | grep mpi3mr
• find /lib/modules/$(uname -r) -type f -name 'mpi3mr*' || modinfo mpi3mr
• Inspect kernel config for driver presence:
• zgrep CONFIG_SCSI_MPI3MR /proc/config.gz || grep CONFIG_SCSI_MPI3MR /boot/config-$(uname -r)
• If CONFIG_SCSI_MPI3MR=y or =m, the driver was built in or as a module.
• Search kernel tree / packaged modules for the unpatched commit indicators:
• If you have access to package source or vendor changelogs, map the kernel revision against the stable commit f195fc060c7… (the upstream commit that introduced the fix) or the stable branch release that included the patch. Upstream commit metadata and stable‑backport lists are public in LKML / stable commit logs.
• For WSL2 users:
• Verify the WSL kernel release tag: uname -r inside a WSL instance.
• Compare against the WSL2‑Linux‑Kernel release tags (Microsoft’s GitHub repository) to determine whether the WSL kernel contained the fix at the time of the WSL kernel build.
• For image catalogs (Azure VM marketplaces, AKS node images):
• Query your inventory for image SKUs in use and cross‑reference Microsoft’s VEX/CSAF attestation for this CVE to see which Azure Linux SKUs are listed as Known Affected or Fixed.
• For Marketplace images, contact the image publisher for kernel package mapping and remediation status.

These verification steps triage presence/absence quickly and produce definitive evidence you can use for patch prioritization.

Remediation and operational guidance​

• If your Azure Linux images are listed as affected by Microsoft’s VEX/CSAF for CVE‑2025‑37861, apply the patched Azure Linux kernel images or vendor kernel updates immediately as they become available and plan controlled reboots to move hosts to patched kernels. Microsoft’s attestation is the authoritative automation input for Azure Linux SKUs.
• If a host’s kernel contains mpi3mr and cannot be patched immediately, consider:
• Removing or blacklisting the mpi3mr module if the hardware is not used on that host.
• Restricting local access to services and users who can interact with SCSI devices or the kernel interfaces used by the driver.
• Isolating vulnerable hosts from multi‑tenant workloads until patched.
• For WSL2 environments, update WSL via Microsoft Update or apply a custom, patched kernel if you run a custom WSL kernel build. Microsoft publishes WSL kernel releases and encourages reporting security issues through MSRC; check the WSL GitHub release notes and update guidance.
• For Marketplace and partner images, coordinate with the image publisher for patches and timelines. Do not assume a Marketplace image is covered by Microsoft’s Azure Linux attestation; many Marketplace images are managed by third parties.

Risk assessment — exploitability and impact​

• Attack vector: local — an unprivileged or low‑privilege process able to interact with the affected SCSI device interface can trigger a crash. Exploiting the bug remotely would typically require a chain that provides local access to the vulnerable interfaces (for example, via a guest VM with passthrough devices, or through an application that has device access). Public reporting and vendor advisories treat this as an availability / denial‑of‑service defect rather than a reliable privilege‑escalation or remote code execution primitive.
• Severity: distributors report medium to high availability impact depending on context and CVSS mapping; practical impact is primarily service disruption and potential controller unrecoverability if the 10‑second wait timeout is exceeded.
• Blast radius: systems that directly attach the affected hardware (servers with the Broadcom/LSI MPI3 controllers) and shared multi‑tenant hosts or CI runners that may expose such devices are higher risk. Hosts without the hardware (or whose kernel does not include the driver) are not affected.

Why you should not treat a single attestation as complete coverage​

Microsoft’s MSRC attestation model is explicitly phased: they started by publishing CSAF/VEX for Azure Linux and will expand product mappings as inventory proceeds. A single attestation is valuable because it gives an authoritative automation signal for the product it covers, but it cannot substitute for per‑artifact inventory when a vendor manages thousands of images, kernels, and third‑party Marketplace content. The practical consequence for operators: treat Microsoft’s Azure Linux attestation as authoritative for that product and as actionable for Azure Linux customers, and treat other Microsoft‑supplied artifacts as unknown until verified.

Recommended action checklist (prioritized)​

• For Azure Linux customers:
• Ingest Microsoft’s CSAF/VEX JSON for CVE‑2025‑37861 and identify impacted SKUs.
• Patch Azure Linux images and schedule reboots for VMs using those SKUs.
• For WSL2 users and developer fleets:
• Check WSL kernel release tags and update WSL or your custom kernels where necessary. If running custom WSL kernels, rebuild with the upstream fix included.
• For all environments:
• Inventory all Microsoft‑published images, Marketplace appliances, and any custom images used in your estate.
• For each image, apply the verification steps above (lsmod/modinfo, kernel config check, package changelog) and track remediation status.
• For Marketplace and third‑party images:
• Open a security escalation with the image publisher if the image includes the vulnerable driver; do not rely on Microsoft’s Azure Linux attestation to cover these images.
• For defenders with limited patch windows:
• Blacklist mpi3mr where it is not needed and apply host hardening to reduce local access to the vulnerable interface.

Caveats and unverifiable claims​

• It is impossible, from public information alone, to assert definitively that no Microsoft product other than Azure Linux contains mpi3mr at any time in any release channel. Microsoft’s statement is an attestation of what they have validated so far; absence of other product mappings is not evidence of universal absence. This is a state‑of‑inventory issue rather than a technical mystery — Microsoft will update the VEX/CSAF product mapping if further Microsoft SKUs are discovered to contain the component. Treat any claim that “Azure Linux is the only Microsoft product affected” as unverifiable until Microsoft explicitly states so across its product catalog.
• Public kernel source trees and stable commit logs confirm the technical fix and the commit identifiers; cross‑checking the exact kernel builds you run against those commit identifiers is necessary to produce a definitive “vulnerable/not vulnerable” determination per host.

Conclusion​

Microsoft’s MSRC attestation that Azure Linux “includes this open‑source library and is therefore potentially affected” is an authoritative, actionable signal for Azure Linux customers and should trigger immediate triage and patching for any Azure Linux images you run. However, that attestation is product‑scoped and phased — it is not a proof that no other Microsoft product contains the mpi3mr driver. Other Microsoft artifacts that ship Linux kernels (notably the WSL2 kernel, linux‑azure kernels, and Marketplace images) can contain the same upstream code depending on build choices, and should be inventoried and verified independently. Follow the verification checklist, prioritize patching for affected Azure Linux SKUs, and verify WSL, Marketplace, and custom images until Microsoft’s VEX/CSAF output explicitly covers them or your host‑level checks confirm the code is absent or patched.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center