CVE-2025-39862 Explained: Azure Linux Exposure and Mt76 Patch

The Linux kernel Wi‑Fi driver patch logged as CVE‑2025‑39862 fixes list corruption in the mt76/mt7915 driver that can occur when hardware is restarted; Microsoft’s Security Response Center (MSRC) has published a product‑scope attestation stating that Azure Linux includes the affected upstream component and is therefore potentially affected, and that Microsoft will update the CVE/VEX mapping if additional Microsoft products are identified as carriers.

Background / Overview​

The underlying defect addressed by CVE‑2025‑39862 is a robustness bug in the MediaTek‑supporting mt76 kernel driver for MT7915-class Wi‑Fi chipsets. Upstream kernel commits clear WCID lists and reset wcid->sta entries before calling ieee80211_restart_hw to avoid stale list entries being re-added during station recreation, a change that prevents list corruption after a hardware restart. The fix was merged into the stable kernel trees as a small, targeted patch. Public vulnerability trackers (NVD, OSV and several distro security trackers) reflect the same technical summary and list the upstream commits and stable backports. These independent mappings provide the canonical evidence for which kernel releases are fixed and which tree commits introduced the remedy. Microsoft’s MSRC update guide entry for CVE‑2025‑39862 highlights Azure Linux as a Microsoft product that “includes this open‑source library and is therefore potentially affected,” and explains Microsoft’s commitment to publish CSAF/VEX attestations and expand them if other Microsoft products are found to include the same upstream code. That MSRC entry is a product‑level attestation — it reports the outcome of Microsoft’s inventory and mapping work for the Azure Linux product family at the time of publication.

---

What Microsoft’s wording actually means​

Product‑scope attestation, not a blanket exclusion​

Microsoft’s language is deliberately scoped: saying Azure Linux “includes this open‑source library and is therefore potentially affected” is an authoritative statement about Azure Linux specifically — it is not, by itself, a guarantee that no other Microsoft product includes the vulnerable driver. The company’s published VEX/CSAF artifacts are a phased, machine‑readable rollout starting with Azure Linux; Microsoft has said it will update attestations as its internal inventories discover additional affected Microsoft SKUs.

Why that distinction matters operationally​

• A vendor attestation is useful because it gives a definitive, automatable signal about the covered product (Azure Linux).
• Absence of attestations for other Microsoft products is not proof of absence. It may simply mean Microsoft has not yet completed the inventory and mapping for those other products.

---

Is Azure Linux the only Microsoft product that includes the mt76 code and could be affected?​

Short answer: No — Azure Linux is the only Microsoft product currently attested by Microsoft as including the upstream mt76 code for CVE‑2025‑39862, but it is not technically guaranteed to be the only Microsoft product that could contain the vulnerable driver.

Why Azure Linux is the only attested product so far​

Microsoft chose to begin its CSAF/VEX rollout with Azure Linux (its cloud distribution artifacts), and that is why Azure Linux appears first and only in the MSRC product mapping for this CVE at publication. The attestation is an authoritative confirmation that customers running Microsoft‑published Azure Linux images should treat those images as in‑scope for remediation.

Why other Microsoft artifacts could include the same driver​

Several Microsoft‑published artifacts either ship Linux kernels or act as host/guest images that depend on Linux kernels. Any of these could include the same upstream mt76 sources — if the kernel build or configuration used for that product includes the mt76/mt7915 driver and the kernel revision predates the upstream fix. Plausible Microsoft artifacts to check include:

• Windows Subsystem for Linux (WSL2) kernel builds — Microsoft maintains a WSL2 Linux kernel tree on GitHub and distributes WSL kernel images. WSL kernel builds historically have included many kernel subsystems, and more recent WSL kernel releases expanded module support; a WSL kernel that includes mt76 and predates the fix would be in scope. However, WSL’s runtime model typically virtualizes networking and many desktop hosts do not present direct Wi‑Fi hardware to WSL; still, a WSL‑distributed kernel image that contains mt76 code would technically be a possible carrier.
• CBL‑Mariner / linux‑azure variants / Azure host images — Microsoft maintains internal Linux artifacts (CBL‑Mariner lineage, linux‑azure kernels and Azure Marketplace base images). These kernel packages are used as host/container base distributions in some Azure infrastructure and therefore are plausible carriers if the kernel builds include mt76. Distribution-level kernel packages (including linux‑azure) have been updated in other mt76 fixes, and Microsoft’s internal distribution artifacts historically appear in its Security Update Guide when an inventory mapping is relevant.
• Azure Marketplace and partner VM images — Marketplace images are often built by Microsoft partners or third parties. Microsoft’s attestation for Azure Linux does not cover every Marketplace image, and some partner images may carry upstream drivers in older kernel packages. Treat Marketplace and partner images as separate artifacts requiring per-image verification.
• AKS node images and container host kernels — Kubernetes node images for Azure and container host kernels are typically built from curated kernel packages; if those packages are Microsoft‑built and use the mt76 code path, they could be in scope.

Evidence & independent cross‑checks​

• The upstream kernel commits and the kernel stable backports are public and are the primary proof that the bug existed and was fixed in mt76/mt7915. Security trackers and distro advisories (Ubuntu, SUSE, Debian and others) list the same kernel fixes and map the fixes into distribution kernel package updates. Those independent repositories corroborate the technical facts and show which packaged kernels received the backports.
• Microsoft’s attestation is visible in its MSRC product mapping and VEX outputs and explicitly ties Azure Linux to the implicated upstream component; Microsoft also stated it will update the CVE record if it identifies additional products that include the same upstream code. That public commitment is not a technical proof of absence for other products — it is a binding operational promise to expand mapping when Microsoft discovers additional carriers.

---

Practical guidance: how to determine exposure in Microsoft‑supplied artifacts you run​

Vulnerability exposure depends on two factors: (1) does the product actually ship a Linux kernel build that includes the mt76/mt7915 driver source, and (2) is that kernel build older than the upstream fix (no backport applied)? Both must be true for runtime exposure.
Follow these prioritized checks.

1) Inventory Microsoft Linux artifacts you run (highest priority)​

• Azure VM and image inventory: any VM using Microsoft-maintained Azure Linux images (the product Microsoft attested) — treat as in‑scope immediately.
• Marketplace VM images, curated container images, AKS node images.
• CBL‑Mariner derived images or Microsoft container host images.
• WSL2 instances across developer fleets and CI runners (if your build or runtime policy depends on the Microsoft‑provided WSL kernel image or you deploy custom kernels derived from the WSL tree).

2) On each suspect host or image: check kernel version and module presence​

On a running Linux host (VM, container host or image shell), run:

• uname -r (check kernel release)
• modinfo mt76 && modinfo mt7915 (if this module exists on the host)
• lsmod | grep mt76
• grep -E "mt76|mt7915" /proc/modules (module presence)
• For packaged kernels, inspect package changelogs and vendor advisories to map to upstream commits and confirm whether the mt76 fix is present in your kernel package.

Notes:

• If mt76 is built into the kernel image (not a separate module), modinfo and lsmod may not show a module — inspect kernel config and package build metadata instead.
• If the kernel release predates the fixed stable release (or your distro vendor’s backport has not been applied), the host is likely vulnerable until patched.

3) WSL‑specific checks​

• WSL2 uses a Microsoft‑maintained kernel image. Check the WSL kernel release on the Windows host with:
• wsl --shutdown
• wsl uname -r (inside a WSL2 distribution)
• Check the WSL2 kernel release tag and the Microsoft/WSL2‑Linux‑Kernel repository for configuration and commits if you need to validate the presence of mt76 in the WSL kernel build. Microsoft’s WSL repo is public and can be inspected to determine whether the shipped kernel contains mt76 sources and whether the fix is present. If you run custom WSL kernels, confirm the build config used.

4) Image‑level or offline artifact inspection​

• Mount the image or inspect image layers to locate /lib/modules/<kernel‑release>/ and search for mt76/mt7915; inspect kernel packages inside the image for version and changelog. For container images, check their base image provenance and package lists.

5) If you find an affected Microsoft artifact​

• Prioritize patching Microsoft‑published Azure Linux images first (they’re attested). For other images or kernels, prioritize hosts based on exposure and tenancy level (multi‑tenant hosts and shared systems first).

---

Recommended remediation and mitigations​

• Apply vendor kernel updates (patched kernel packages that include the upstream mt76/mt7915 fix) as soon as they are available for the affected kernel package in your platform (Azure Linux, linux‑azure, CBL‑Mariner, your distro’s kernel package). Reboot as required to load the updated kernel. Upstream stable commits were applied to kernel stable branches and distro vendors have integrated the fix; use your distro’s security update channels.
• For WSL2 users: If the WSL kernel shipped by Microsoft is updated to a patched release, update WSL via the normal WSL update mechanisms. If you use a custom kernel, rebuild with the upstream fix or switch to a Microsoft‑supplied patched WSL kernel release.
• If immediate patching is not possible:
• Remove or disable the mt76/mt7915 kernel module where feasible (rmmod mt7915 mt76) on hosts where doing so won’t impair required functionality.
• Limit local untrusted access to hosts that run the affected driver (restrict container privileges, sandbox untrusted workloads, and tighten guest/tenant isolation).
• Monitor kernel logs (dmesg, journalctl) for mt76/mt7915 errors and for repeated hardware restart patterns that align with the reported bug symptoms.
• Automation:
• Ingest Microsoft’s CSAF/VEX machine‑readable artifacts for Azure Linux and any subsequent Microsoft attestations into your vulnerability orchestration and SIEM. Microsoft committed to publishing these attestations and to updating them if additional Microsoft products are found to include the component; automating parsing of these VEX files will make future changes actionable.

---

Risks, caveats and unverifiable items​

• WSL kernel builds and configurations vary across releases and custom builds. Whether WSL instances in your environment are actually vulnerable depends on the specific WSL kernel release and configuration used on each Windows host; while WSL’s kernel source is public and can be inspected, determining exposure requires host‑by‑host checks. Treat any statement about “WSL is/ is not vulnerable” as conditional on the exact kernel release and config.
• Microsoft’s attestation naming Azure Linux is a snapshot in time. Microsoft explicitly pledged to update the CVE/VEX mapping if they find additional Microsoft products include the vulnerable component; therefore the set of Microsoft products Microsoft publicly lists as affected can grow. Do not assume absence of evidence in MSRC means absence of vulnerability in your estate.
• In many cases, kernel drivers are included or omitted at build time. Even within a single vendor (including Microsoft), different artifact families (Azure VM images, WSL kernel, CBL‑Mariner images, Marketplace images) can have different kernel configs and package versions — you must verify the actual artifact you run rather than relying on product‑level heuristics alone.

---

Key takeaways and recommended next steps​

• Azure Linux is the only Microsoft product Microsoft has publicly attested as including the affected mt76/mt7915 driver for CVE‑2025‑39862 at the time of the MSRC announcement — that attestation is authoritative for Azure Linux and should be acted on immediately.
• That attestation does not prove that no other Microsoft product contains the vulnerable code. Other Microsoft‑distributed Linux artifacts (notably the WSL2 kernel, CBL‑Mariner lineage artifacts, linux‑azure kernels, and Marketplace images) are plausible carriers if their kernels were built with mt76/mt7915 sources from the vulnerable upstream range. Customers must perform artifact‑level verification across their estate.
• Immediate operational steps:
• Treat Azure Linux images as in‑scope and apply Microsoft’s recommended updates / patched kernel images for any affected Azure Linux VMs and services.
• Inventory other Microsoft Linux artifacts you run (WSL, Marketplace images, AKS node images, CBL‑Mariner hosts) and verify kernel versions and module presence with the checks described above.
• Ingest Microsoft’s CSAF/VEX outputs for automation and watch for updates as Microsoft expands attestations to additional products.

---

Conclusion
Microsoft’s MSRC statement is useful and clear: Azure Linux includes the upstream mt76 code path and is potentially affected, and Azure Linux customers should treat that attestation as authoritative and remediate using Microsoft’s updates. However, the attestation is scoped to the product Microsoft has inventoried and does not, by itself, exclude the possibility that other Microsoft‑shipped Linux artifacts (WSL2 kernels, CBL‑Mariner / linux‑azure artifacts, Marketplace images and others) might also include the vulnerable driver depending on kernel build and configuration. The correct operational posture is immediate remediation for attested Azure Linux images, concurrent artifact‑level verification across all Microsoft Linux artifacts in your estate, and automation of future Microsoft VEX/CSAF updates so additional attestations are consumed as they are published.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center