Microsoft’s short answer — that “Azure Linux includes this open‑source library and is therefore potentially affected” — is correct as a product‑level attestation, but it is not a technical guarantee that Azure Linux is the only Microsoft product that could contain the vulnerable mt76/mt7915 driver. The distinction matters: an MSRC attestation identifies the presence of an upstream component in a named Microsoft product, yet the same upstream source can and often does appear in other Microsoft artifacts (custom kernels, marketplace images, WSL kernels, container images, and partner appliances) depending on how those artifacts were built and configured.
CVE‑2025‑38155 is a Linux kernel vulnerability in the mt76 wireless driver family — specifically a null pointer dereference in mt7915_mmio_wed_init() when devm_ioremap() returns NULL and that return value was not checked. The upstream kernel team assigned the CVE, and the fix was merged into the stable kernel trees; public vulnerability databases and the kernel CVE announcements list the affected commits and the fixed revisions. This class of bug is an availability and stability risk (kernel oopses/crashes) and has a local/adjacent attack vector.
Microsoft’s Security Response Center (MSRC) has published a product‑scope attestation mapping the upstream component to Azure Linux (the Microsoft‑published distro formerly known as CBL‑Mariner). The FAQ entry on Microsoft’s vulnerability pages repeats the policy line you've quoted: Azure Linux is known to include the upstream library and is therefore potentially affected, and Microsoft has committed to expand machine‑readable CSAF/VEX attestations and to update the CVE mapping if additional Microsoft products are later found to ship the same component. That is an important operational signal for Azure Linux users — but it is not an exhaustive inventory of every Microsoft artifact.
For immediate action: patch Azure Linux images now, scan your WSL/Marketplace/AKS/CI images for mt76/mt7915, and schedule rebuilds where necessary — those steps will close the practical attack surface while you wait for vendor attestations to expand.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE‑2025‑38155 is a Linux kernel vulnerability in the mt76 wireless driver family — specifically a null pointer dereference in mt7915_mmio_wed_init() when devm_ioremap() returns NULL and that return value was not checked. The upstream kernel team assigned the CVE, and the fix was merged into the stable kernel trees; public vulnerability databases and the kernel CVE announcements list the affected commits and the fixed revisions. This class of bug is an availability and stability risk (kernel oopses/crashes) and has a local/adjacent attack vector.Microsoft’s Security Response Center (MSRC) has published a product‑scope attestation mapping the upstream component to Azure Linux (the Microsoft‑published distro formerly known as CBL‑Mariner). The FAQ entry on Microsoft’s vulnerability pages repeats the policy line you've quoted: Azure Linux is known to include the upstream library and is therefore potentially affected, and Microsoft has committed to expand machine‑readable CSAF/VEX attestations and to update the CVE mapping if additional Microsoft products are later found to ship the same component. That is an important operational signal for Azure Linux users — but it is not an exhaustive inventory of every Microsoft artifact.
Why customers ask “Is Azure Linux the only Microsoft product affected?”
Enterprise operators and security teams need to know which artifacts in their environments are vulnerable in order to prioritize patching, schedule reboots, and meet compliance requirements. When a major vendor publishes an attestation that a given product includes a vulnerable upstream library, two natural but distinct interpretations follow:- A narrow, operational interpretation: “Microsoft confirmed Azure Linux ships the vulnerable component, so patch Azure Linux images now.” This is correct and immediately actionable.
- A broader supply‑chain interpretation: “Does Azure Linux being attested mean that no other Microsoft product contains the code?” This interpretation is not supported by the attestation alone. Microsoft’s attestation is scoped to the named product; absence of attestations for other products is not proof those other products are clean. Microsoft has said it will expand VEX/CSAF attestations over time, but until then artifact‑level verification remains necessary.
Technical reality: where the same upstream code can appear
The Linux kernel source tree provides the driver code (mt76, mt7915) that downstream builders compile into kernels or kernel packages. Microsoft’s supply chain includes multiple places where that same code could appear:- Azure Linux kernel packages and VM images (this is exactly what MSRC inspected and attested).
- WSL2 kernel images distributed by Microsoft for Windows Subsystem for Linux: Microsoft provides a kernel image for WSL2 and also supports custom WSL kernels; those kernels may include or omit drivers depending on the build configuration. Operators running the Microsoft‑supplied WSL kernel should treat it as a distinct artifact and verify whether the driver is present.
- Azure Marketplace VM images and publisher images: third‑party or Microsoft‑published images in the marketplace are independent artifacts; some may be rebuilt from the same base trees, others may be custom and include extra modules.
- AKS node images, container host images, and managed node pools: images used for container hosts or managed nodes can vary by SKU and build pipeline; nodes built from an attested Azure Linux image are in scope, but others might be built differently.
- Microsoft developer tools or desktop components that ship custom kernels or kernel modules (for example, some virtualization or developer tools embed kernel images). Any such custom kernel is a separate build artifact and must be inspected.
What Microsoft’s wording does and does not mean
What the MSRC sentence does mean (accurately and usefully)- Microsoft inspected the Azure Linux product family and found the upstream component mapped to the CVE; therefore Azure Linux images are in‑scope and should be patched or updated per Microsoft guidance. That is an authoritative, actionable declaration for that product.
- It does not state, and should not be read as, an exhaustive inventory of every Microsoft artifact. It does not declare that other Microsoft products cannot include the same vulnerable code. Absence of a public attestation for another product does not equate to absence of vulnerability in that product.
Cross‑checking the technical facts (what upstream sources show)
The kernel CVE team and downstream vulnerability databases record the technical details:- The kernel announcement (linux‑cve‑announce) documents CVE‑2025‑38155, describes the null‑pointer dereference in mt7915_mmio_wed_init(), and records the introduction and the upstream fix (fix commit merged into stable trees). This is the canonical upstream engineering record.
- Public trackers such as NVD, OSV, and distribution security trackers (Debian security tracker, OpenCVE) reflect the CVE, affected kernel ranges, and the fix. These entries corroborate the technical details and severity classification.
Operational risk: where the real blind spots are
A vendor attestation is only as useful as your ability to map vendor artifacts to the images or binaries running in your estate. Common blind spots include:- Image drift and derivative images: organizations often build internal images atop vendor base images. If a base image (or its kernel) is vulnerable and your internal image is not rebuilt with the patched kernel, the vulnerability can persist.
- Marketplace and partner images: images published to an enterprise marketplace or supplied by partners may not inherit the same build provenance as Azure Linux and must be audited separately.
- Custom kernels and developer images: WSL2, developer VMs, and certain Microsoft tools permit custom kernel builds or ship their own kernels; each custom kernel is a separate artifact to inspect.
- Embedded devices and appliances: devices or appliances that Microsoft ships as partner solutions or that use Microsoft tooling may include kernels or modules patched differently. The absence of a vendor attestation for these SKUs is not evidence of safety.
Practical verification and remediation checklist
Below are concrete steps your ops or security team should run now to close the real risk window.- Prioritize Azure Linux artifacts (attested)
- Apply Microsoft’s updated Azure Linux images or patched kernel packages first. Microsoft’s attestation makes these the highest‑priority Microsoft artifacts.
- Inventory Microsoft artifacts in your estate
- Enumerate VMs, container hosts, WSL2 instances, Marketplace images, AKS node images, and any Microsoft‑distributed developer images.
- For each artifact, record the kernel version, distribution, and build provenance.
- Artifact‑level checks (repeatable)
- On a running Linux host / VM / container: run:
- uname -r (to get the running kernel)
- sudo lsmod | grep mt76
- sudo modinfo mt7915 (or modinfo mt76)
These commands confirm whether the mt7915 driver or mt76 modules are present and loaded. - For WSL2: from within the WSL shell run uname -r and inspect for a Microsoft-supplied kernel tag (e.g., “-microsoft-standard‑WSL2”); update WSL with elevated host commands if the MSRC guidance indicates a WSL kernel update is required.
- Image scanning and SBOMs
- Use image scanners and SBOM tools to search for mt76, mt7915, or the upstream commit identifiers in kernel packages or module tarballs embedded in images.
- Where vendors (including Microsoft) supply SBOMs or VEX/CSAF files, ingest those machine‑readable attestations and map them against your inventory. Microsoft’s VEX rollout will make this easier over time; until then, rely on direct scanning and SBOMs from your CI pipeline.
- Temporary mitigations when patch/rebuild is unavailable
- If a host does not need wireless support, blacklist the module (for example, create /etc/modprobe.d/blacklist-mt76.conf containing “blacklist mt76” and rebuild initramfs as appropriate).
- In cloud images where you cannot safely reboot, isolate affected images from untrusted tenants or reduce local unprivileged access that can trigger the vulnerable code.
- Use module blacklisting as a stopgap only; it removes functionality and is not a replacement for the upstream fix.
- Verify patch presence
- Confirm the kernel package version on patched hosts matches vendor advisories or contains the upstream commit referenced in the kernel CVE announcement. Vendor changelogs and stable‑tree commit identifiers are the strongest verification.
- Keep an eye on VEX/CSAF updates
- Microsoft is publishing machine‑readable VEX attestations starting with Azure Linux and has said it will update CVE mappings if more products are identified as carriers. Ingest MSRC CSAF/VEX as it becomes available to reduce uncertainty.
Strengths and limits of Microsoft’s approach (analysis)
Strengths- Authoritative attestation for Azure Linux: Microsoft’s MSRC note gives Azure Linux customers a clear, actionable signal to patch their images first. That clarity is operationally helpful and reduces false positives.
- Machine‑readable VEX/CSAF rollout: Committing to VEX/CSAF makes it possible to automate product‑level impact mapping at scale, which is a material improvement for customers and security vendors.
- Attestation scope is product‑scoped, not artifact‑exhaustive. A single vendor ships many independent artifacts; product attestation identifies a family (Azure Linux) but does not automatically enumerate every kernel image or marketplace artifact that could carry the code. Absence of an attestation for WSL2, Marketplace images, AKS node images, or other Microsoft artifacts is not proof of absence.
- Supply‑chain complexity and image drift. Organizations build derivative images and may embed vulnerable kernels from vendor images long after a vendor publishes a fix; these downstream artifacts must be rebuilt and redeployed.
- Custom kernels and developer tooling. Microsoft’s tools and developer product ecosystem permit custom kernel images; these require separate inspection.
Recommendations for defenders (short checklist)
- Treat Microsoft’s Azure Linux attestation as a high‑priority remediation signal and patch Azure Linux images immediately.
- Run artifact‑level discovery across all Microsoft‑distributed images you run: WSL2 kernels, Marketplace images, AKS node images, developer and CI images, and any custom kernels. Use uname/modinfo/lsmod on running hosts and image scanners/SBOMs for stored artifacts.
- Ingest MSRC CSAF/VEX feeds as they appear; they will reduce noise and automation burden over time. Until then, do not assume non‑attested products are clean.
- Where immediate patching is impossible, use module blacklisting or isolation to reduce risk temporarily. Plan for rebuilds and full rollouts as soon as vendor packages or patched images are available.
- Verify patches by checking kernel package versions, changelogs, or presence of the upstream commit noted by the kernel CVE team. Cross‑reference the kernel CVE announcement and vendor advisories.
Conclusion
Microsoft’s MSRC attestation that Azure Linux includes the upstream mt76/mt7915 component and is therefore potentially affected by CVE‑2025‑38155 is useful and correct — it tells Azure Linux customers what they must do first. However, it does not prove exclusivity. The same upstream driver source can and does show up in other Microsoft artifacts depending on how those artifacts were built, and the absence of a public attestation for another Microsoft product is not evidence that product is unaffected. Customers should prioritize patching Azure Linux per MSRC’s guidance, ingest MSRC CSAF/VEX outputs as they are published, and run artifact‑level discovery (SBOMs, image scans, module checks) across all Microsoft‑supplied and Microsoft‑built artifacts they run until attestations and inventories conclusively demonstrate those artifacts are clean.For immediate action: patch Azure Linux images now, scan your WSL/Marketplace/AKS/CI images for mt76/mt7915, and schedule rebuilds where necessary — those steps will close the practical attack surface while you wait for vendor attestations to expand.
Source: MSRC Security Update Guide - Microsoft Security Response Center
