Microsoft’s public attestation that “Azure Linux includes this open‑source library and is therefore potentially affected” should be read as a deliberate, product‑scoped inventory statement — authoritative for Azure Linux, useful for automation, but not proof that no other Microsoft product can or does ship the same vulnerable upstream code.
Background / Overview
On January 11, 2025 the Linux kernel community recorded and fixed a defect tracked as CVE‑2024‑57804: a race/logic bug in the Broadcom/LSI MPI3 SCSI driver (mpi3mr) that could corrupt SAS controller config pages when PHYs are toggled rapidly via the sysfs interface. The issue arises because the driver reused the same memory for multiple config requests; under rapid enable/disable operations the persistent and current config pages for SAS IO units or expanders could become corrupted. The National Vulnerability Database (NVD) and multiple distribution security trackers list the CVE and its high‑level description. This is an availability/robustness class bug — the practical risk is kernel oopses, storage controller misconfiguration, and in some vendor builds the potential for the controller to become unrecoverable or to require reinitialization. Public advisories and patch notes (Debian, Oracle Linux, Amazon ALAS and others) document fixed kernel package versions and stable‑tree commits that remedied the problem. Microsoft’s Security Response Center (MSRC) entry for this CVE takes a product‑attestation approach: the company published a machine‑readable CSAF/VEX attestation that maps upstream components into particular Microsoft product SKUs and explicitly states Azure Linux “includes this open‑source library and is therefore potentially affected.” Microsoft also committed to expand the VEX/CSAF mapping and update the CVE entry if other Microsoft products are later discovered to ship the same component. That phrasing is intentional and procedural — it documents what Microsoft has validated so far, not what it has
not.
What the CVE actually is (technical summary)
- Component: Linux kernel SCSI driver mpi3mr (Broadcom/LSI MPI3 family).
- Fault: reuse of a single buffer for multiple config page requests; when multiple PHY enable/disable operations occur in quick succession, config-page memory could be overwritten leading to corrupted persistent/current config pages for SAS IO unit/expander responses.
- Impact: local/administrative interface can induce kernel log errors, config corruption, and potential controller instability or unrecoverable states.
- Exploitability: local — an attacker or automated script with the ability to write to sysfs entries controlling PHYs (for example, /sys/class/sas_phy/*/enable) can trigger the condition; exploitation does not appear to provide a reliable remote code execution or privilege escalation primitive in public reporting, but can cause host/service disruption.
Multiple upstream stable commits and distribution advisories show the fix is small and targeted: allocate separate memory for each config request, or serialize access so that concurrent/rapid sysfs toggles cannot share the same buffer. Distributors have integrated those stable commits into patched kernel packages; Debian, Oracle, Amazon and other distributors maintain package mappings to indicate which releases are affected or fixed.
What Microsoft said — precise reading and practical meaning
Microsoft’s phrasing — “Azure Linux includes this open‑source library and is therefore potentially affected” — performs two functions:
- It provides an authoritative, machine‑readable attestation for Azure Linux SKUs that Microsoft has inventoried and validated. Customers running those SKUs can consume Microsoft’s CSAF/VEX artifacts to automate triage and remediation.
- It signals that Microsoft’s VEX/CSAF rollout is phased: Azure Linux was the first product family to get this machine‑readable inventory coverage (the company began publishing CSAF/VEX attestations in October 2025), and Microsoft will update the CVE/VEX records if additional Microsoft SKUs are discovered to carry the vulnerable component. That pledge is procedural — it commits Microsoft to expand product mappings as its internal inventory work proceeds.
Crucially, this wording is not an explicit denial that other Microsoft products may include the same upstream driver. Absence of a VEX/CSAF attestation for a product is not evidence that the product is free from the code; it may simply mean Microsoft’s inventory for that product is not yet complete. Independent analysts and operator guidance emphasize this distinction: treat Microsoft’s Azure Linux attestation as authoritative for Azure Linux, but verify other Microsoft‑provided artifacts yourself.
Is Azure Linux the only Microsoft product that includes mpi3mr?
Short answer: No — not necessarily. Microsoft has publicly attested that Azure Linux ships the implicated upstream component for CVE‑2024‑57804 and therefore is potentially affected; that attestation is authoritative and actionable for Azure Linux customers. However, it is not proof that no other Microsoft product, image, kernel artifact, or Marketplace appliance could include the same open‑source mpi3mr driver or the vulnerable commit range.
Why the short answer matters:
- Kernel artifacts are an artifact‑level property. Whether a particular Microsoft product ships a driver depends on build configuration (CONFIG_SCSI_MPI3MR enabled as built‑in or module), the kernel version shipped, whether a vendor backport was applied, and whether the image is a Microsoft‑controlled image or a partner/Marketplace image. Two Microsoft artifacts built from different kernel trees or with different kernel configs can differ on whether mpi3mr is present.
- Microsoft operates multiple Linux artifact families that plausibly can carry the same upstream sources — for example, the WSL2 kernel source tree the company publishes, linux‑azure kernel builds, CBL‑Mariner derivatives, Azure Marketplace VM images, and curated container base images. Any of those may or may not include mpi3mr depending on build choices. The only authoritative way to determine presence is artifact inspection or a vendor attestation for that SKU.
- Microsoft explicitly promises to update the VEX/CSAF mapping and the CVE if additional Microsoft products are identified as carriers. Until Microsoft publishes such an update, customers should assume unknown Microsoft artifacts might contain the vulnerable code and verify them accordingly.
How to determine whether a given Microsoft (or non‑Microsoft) artifact is affected — tactical checklist
The only way to produce a definitive “vulnerable / not vulnerable” statement for a host or image is to verify the running artifact. Use the following artifact‑level checks (quick triage commands and steps):
- On a running Linux host (Azure VM, on‑prem, WSL2, container host)
- Identify the running kernel: uname -r
- Check for the mpi3mr module: lsmod | grep mpi3mr
- Search modules directory: find /lib/modules/$(uname -r) -type f -name 'mpi3mr*'
- Show module metadata: modinfo mpi3mr (if present)
- Inspect kernel config for build-time inclusion: zgrep CONFIG_SCSI_MPI3MR /proc/config.gz || grep CONFIG_SCSI_MPI3MR /boot/config-$(uname -r)
- Review kernel package changelog for CVE or upstream commit IDs: apt changelog linux-image-$(uname -r) | grep -i 57804 (Debian/Ubuntu) or rpm -q --changelog kernel | grep -i 57804 (RHEL/CentOS/SUSE).
- For WSL2 instances
- Run uname -r inside WSL to see the kernel version.
- If using Microsoft’s published WSL kernel, check the WSL2‑Linux‑Kernel release tags (GitHub) and the kernel config used for builds.
- If you supply a custom WSL kernel, rebuild with the upstream fix applied.
- For Azure images and Marketplace appliances
- Ingest Microsoft’s CSAF/VEX JSON for this CVE and map the SKUs you run to the attestation’s Known‑Affected or Fixed fields.
- For Marketplace and partner images, ask the image publisher for kernel package mapping; do not assume the Microsoft Azure Linux attestation covers a Marketplace image unless Microsoft explicitly lists it.
- For offline images or appliance ISOs
- Mount and inspect /boot/config‑* in the image or extract the kernel to check for CONFIG_SCSI_MPI3MR settings.
- Inspect the kernel binary or module list inside the image to confirm the driver presence.
- For large fleets
- Automate checks with orchestration tools: run remote commands to query uname, lsmod, and the kernel config; ingest Microsoft’s VEX/CSAF feed into your vulnerability orchestration; track remediation statuses per image SKU.
If you find mpi3mr present but cannot apply a patch immediately:
- Blacklist the mpi3mr module on hosts that do not attach Broadcom/LSI MPI3 hardware: echo "blacklist mpi3mr" > /etc/modprobe.d/blacklist-mpi3mr.conf and update initramfs as needed.
- Isolate hosts that attach SAS controllers from multi‑tenant workloads or CI runners until patched.
- Tighten local access controls so fewer users and processes can write to /sys/class/sas_phy/*/enable.
- Add kernel logging and alerting for repeated SAS errors (monitor dmesg/journalctl for mpi3mr, sas, mpt3mr, or scsi error strings).
Patching and remediation guidance
- Apply vendor kernel updates that include the stable‑tree commits which fix CVE‑2024‑57804. Distribution trackers list the fixed package versions by distribution and release; check your distro’s security advisory for the exact package to install. Debian, Oracle, Amazon and others have published fixed package mappings.
- For WSL2 users: update WSL via Microsoft Update when Microsoft publishes a patched WSL kernel build, or substitute a custom patched WSL kernel if you maintain a custom build. Verify the WSL kernel version inside the WSL instance after the update.
- For Azure Linux customers: ingest Microsoft’s CSAF/VEX attestation (published for Azure Linux) and follow Microsoft’s recommended remediation steps for the SKUs you run. Microsoft has stated that Azure Linux is a confirmed hit for the attestation, and Azure Linux customers should prioritize patching accordingly.
- For Marketplace appliances and partner images: coordinate with the image publisher. Updates may require the publisher to release a new image or patch the embedded kernel; Microsoft’s Azure Linux attestation does not automatically cover third‑party Marketplace SKUs.
Why Microsoft’s attestation model is both helpful and limited — critical analysis
Strengths
- Authoritative automation signal: Microsoft’s machine‑readable CSAF/VEX artifacts for Azure Linux provide a clear, automatable input for triage pipelines. This reduces time to remediation for customers who consume those artifacts.
- Transparency commitment: Microsoft’s pledge to expand VEX mappings when more products are found to ship the same upstream code improves vendor transparency relative to the old model of terse CVE notes.
Limits and risks
- Product‑scoped scope is not universal coverage: a VEX/CSAF attestation for Azure Linux applies to the product family it names. It is not an exhaustive scan of every Microsoft image, appliance, or kernel binary. Treating it as such would be an inventory error.
- Long tail of artifacts: Microsoft and other large vendors ship thousands of images and kernel artifacts. Marketplace images, partner appliances, static appliance kernels, and custom WSL kernels can all diverge; these are likely to be the hardest to prove absent the vulnerable code.
- Timing gap: Microsoft’s internal inventory and product‑mapping take time. There can be a window between discovery, internal mapping, and public VEX expansion; during that window operators must assume “unknown” artifacts might be carriers.
Operationally, the right posture is to treat Microsoft’s Azure Linux attestation as the authoritative remediation signal for Azure Linux images, but to
not infer safety for other Microsoft artifacts until you have verified them or Microsoft has explicitly attested to them as well.
Cross‑checking and independent corroboration
This assessment aligns with multiple independent trackers and vendor advisories:
- The NVD entry for CVE‑2024‑57804 records the CVE description and links to the publicly available kernel fixes.
- The Debian security tracker lists affected/fixed package versions and references the upstream stable commits.
- Oracle and Amazon vendor trackers published advisory pages that map the CVE to their kernel packaging and release dates.
- Multiple public CVE mirrors and technical posts (for example, CVE.news and CVE Details) summarize the vulnerability, provide technical context, and point to the upstream patches.
These independent sources corroborate the technical diagnosis of the bug, the class of impact (availability), and the presence of stable‑tree fixes that distributors have adopted.
Recommendations for WindowsForum readers and system operators
- Prioritize patching Azure Linux images immediately if Microsoft’s CSAF/VEX attestation lists your SKUs as Known Affected. Use Microsoft’s attestation as a canonical automation input for Azure Linux remediation.
- Inventory every Microsoft‑published artifact you run: WSL kernels, Azure Marketplace images, linux‑azure kernels, CBL‑Mariner derivatives, and any vendor/partner appliances. Verify kernel versions and module presence with the commands above; do not assume Microsoft’s Azure Linux attestation covers them.
- For images you cannot patch in place (static appliances), obtain updated images from the vendor or rebuild and redeploy; updating OS packages will not change a statically embedded kernel image.
- Automate VEX/CSAF ingestion: parse Microsoft’s machine‑readable attestations and correlate SKU lists against your inventory to triage quickly when Microsoft expands its mappings.
- If immediate patching is impossible, reduce the attack surface: blacklist the mpi3mr module where not needed, restrict access to /sys/class/sas_phy/* interfaces, isolate hosts that attach SAS controllers, and monitor kernel logs for recurrent SAS/mpt3mr errors.
Flags, caveats, and unverifiable items
- It is impossible from public information alone to assert categorically that no Microsoft product other than Azure Linux includes mpi3mr at any point across every release channel and build. Doing so would require Microsoft to publish exhaustive VEX/CSAF attestations for every artifact or for an operator to inspect every binary image in question. Until Microsoft explicitly publishes attestations for additional SKUs, any claim that “Azure Linux is the only Microsoft product affected” should be treated as unverifiable.
- Some internal or partner images in Azure Marketplace might include older kernels or custom kernels that are not covered by Microsoft’s Azure Linux attestation; those require publisher confirmation. Microsoft’s public commitment to update the CVE mapping if additional products are identified provides a remediation path, but it may lag internal discovery.
- If you need precise, host‑level evidence for compliance or incident response, perform the artifact‑level checks listed earlier (lsmod, modinfo, kernel config, package changelog) and capture the outputs as evidence; these checks are definitive for a running artifact.
Conclusion
Microsoft’s MSRC attestation that “Azure Linux includes this open‑source library and is therefore potentially affected” is an important and actionable signal: it tells Azure Linux customers they must triage and patch. That attestation is deliberately scoped to the product family Microsoft has validated and is not a universal statement about every Microsoft artifact. Operators must therefore treat the Azure Linux VEX/CSAF output as authoritative for Azure Linux, but must still perform artifact‑level verification across other Microsoft‑supplied images and kernels (WSL2, Marketplace appliances, linux‑azure builds, custom WSL kernels, etc. until Microsoft expands its attestations or the artifact is otherwise verified.
Apply vendor kernel updates where available, automate VEX ingestion for Azure Linux SKUs, inventory all Microsoft images you run, and use the technical detection checklist above to establish definitive exposure for each host or image. These steps reduce triage time, close the verification gap that large vendors’ phased attestations create, and ensure operational continuity in the face of kernel‑level availability defects such as CVE‑2024‑57804.
Source: MSRC
Security Update Guide - Microsoft Security Response Center