Microsoft’s brief advisory about CVE-2025-39711 correctly identifies a bug in the Linux kernel’s IVSC media/MEI stack —
a use‑after‑free in the IVSC (Intel Visual Sensing Controller) transport that can cause a crash at shutdown — and it names
Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” but that attestation is product‑scoped and
does not by itself prove that other Microsoft artifacts are free from the same upstream code.
Background / Overview
The bug tracked as
CVE‑2025‑39711 was fixed upstream by adding missing mei_cldev_disable() calls in the IVSC ACE and CSI driver remove() paths. The root cause: the MEI client structure remained on the mei_device->file_list after the MEI client memory was freed, producing a slab‑use‑after‑free when mei_cl_all_disconnect() later walked that list during shutdown. The defect is a classic lifecycle management error that becomes visible with KASAN-enabled kernels and during the teardown sequence triggered at platform device unregister time.
IVSC (Intel Visual Sensing Controller) is a relatively recent addition to the Linux kernel’s MEI/ME (Management Engine Interface) family. The transport supports camera sharing and firmware downloading between the host and the IVSC device; it is enabled by kernel config options such as CONFIG_INTEL_MEI_VSC and CONFIG_INTEL_MEI_VSC_HW and appears in kernel trees beginning in the 6.8+ series. That means distributions that build kernels with those configs or include mei‑vsc modules can carry this code.
What the CVE and upstream patches show
- The public CVE summary and aggregated trackers (NVD, OSV, CVE aggregators) describe the same technical path: missing mei_cldev_disable() calls in the ACE and CSI drivers lead to a use‑after‑free on shutdown. The NVD entry documents the KASAN slab‑use‑after‑free trace visible when the error is triggered.
- The patch was accepted into the stable kernel trees (notably the 6.16‑stable queue) shortly after the report was prepared, showing an upstream remedy was developed and propagated to stable kernels. Distributors tracking upstream stable kernels will include that fix as they roll forward.
- The IVSC driver was introduced earlier (LKML patches adding mei/vsc transport and firmware loader) and the affected code is located in the misc/mei family of drivers. That historical context clarifies why a runtime shutdown/teardown path would exercise the MEI client list and why missing disable calls are fatal in the particular sequence described by the CVE.
Is Azure Linux the only Microsoft product potentially affected?
Short answer:
No — not necessarily. The MSRC wording the user quotes is precisely an attestation that
Azure Linux has been inventory‑checked and found to include the upstream component implicated by this CVE; Microsoft has also committed to publishing CSAF/VEX attestations for Azure Linux and to update CVE records if additional Microsoft products are identified. However, an MSRC attestation naming Azure Linux is a product‑scoped inventory statement — it confirms Azure Linux as a known carrier, it does not serve as a global exclusion for other Microsoft products that might ship the same kernel code. Treat Azure Linux as a confirmed hit, and treat other Microsoft artifacts as “not yet attested” rather than “not affected” until they are validated.
Why that distinction matters in practice: many Microsoft teams and services build or distribute Linux kernel artifacts independently (for example: WSL2 kernel builds, linux‑azure kernels used in some Azure images, Marketplace virtual machine images, AKS node images, and other appliance or image artifacts). Each artifact is produced from a particular kernel version, configuration and set of patches. The mere fact that Microsoft has one product (Azure Linux) that contains an upstream file does not logically exclude the same file from appearing in other artifacts that Microsoft distributes or maintains. Several WindowsForum analyses and vendor advisories have made this same operational point about product‑scoped attestations.
Which Microsoft products and artifacts are plausible carriers?
This is an operational, artifact‑level question. Here are the Microsoft artifacts that are plausible carriers — reasoning and evidence follow:
- Azure Linux distribution images (attested) — Microsoft explicitly maps the upstream component to Azure Linux in its VEX/CSAF rollouts. That makes Azure Linux an authoritative vector for immediate mitigation.
- WSL2 kernel builds — Microsoft publishes and maintains WSL2 kernel sources and periodic binary builds. The WSL2 kernel source trees have historically included many standard drivers; whether a particular WSL2 binary is affected depends on the kernel version and whether the IVSC/MEI transport was built into that kernel configuration. Independent threads have pointed out that WSL kernels can include common DRM and other drivers found in upstream linux trees, so WSL kernels merit inventory checks.
- linux‑azure/azure‑marketplace kernels — Some Azure Marketplace images and cloud artifacts rely on Microsoft‑maintained kernel builds or on kernels compiled by third parties but packaged by Microsoft. Those images can carry the same upstream sources when built from kernel releases that include IVSC. Microsoft’s attestation practice includes a promise to expand mappings (CSAF/VEX) if other products are found to include the same component; until then, these artifacts are simply unverified.
- AKS node images and other managed Linux node images — Managed Kubernetes node images and PaaS stacks often use curated kernels or guest images. If a given node image uses a kernel build containing MEI/IVSC, the vulnerability could be present. This is an areuld inventory images and node kernels. (This is an operational caution, not an assertion that a specific AKS base image is currently affected.)
Concrete verification requires checking the kernel build and configuration for the presence of the mei‑vsc module or CONFIG_INTEL_MEI_VSC and related options — the location and name of the module are standard (mei‑vsc / mei‑vsc‑hw under drivers/misc/mei in upstream trees). Tools and simple checks are described below in the mitigation section.
Technical analysis — how exploitable and how severe?
CVE‑2025‑39711 is a use‑after‑free (CWE‑416) revealed in the shutdown sequence. The technical characteristics imply:
- The vulnerability arises during shutdown/unregister of platform devices (vsc_tp_shutdown → platform_device_unregister → mei_vsc_remove → mei_cl_all_disconnect). Triggering the error reliably requires the IVSC transport and MEI clients to be present and the removal sequence to execute in the vulnerable order.
- Many public trackers rate the issue as high severity (examples show CVSS scores in the high range), primarily because use‑after‑free conditions can, in some circumstances, escalate beyond crashes to arbitrary code execution. However, the practical exploitability depends on local access, the ability to arrange the device teardown at the right time, and whether the vulnerable code is present in a given kernel build. At present there are no public proofs‑of‑concept showing remote exploitation.
- The presence of KASAN traces in reports indicates the bug is visible to kernel sanitizers; that helps researchers and packagers identify and confirm the fix but also means exploitability analysis should be cautious: KASAN amplifies detection of use‑after‑free faults but does not change the underlying vulnerability class.
Bottom line: the issue is serious enough to warrant prompt patching in any kernel images that include IVSC/MEI client transport code, but the exploitability for remote threat actors is limited by the local, device‑dependent nature of the bug.
Evidence and cross‑checks
I cross‑checked multiple independent sources to verify the technical claims and the product‑scope wording:
- The NVD entry for CVE‑2025‑39711 documents the use‑after‑free and reproduces the KASAN trace details referenced in upstream discussion.
- The upstream kernel commit and stable‑queue entry show the patch and its addition to the stable 6.16 tree, confirming a fix was authored and accepted into stable maintenance. That is a primary source for the technical remedy.
- Historical LKML patches and the CONFIG documentation confirm IVSC’s presence as CONFIG_INTEL_MEI_VSC and the module names (mei‑vsc), which explains how distributions include or exclude this feature at build time. That supports the claim that presence of the code is a per‑artifact kernel build decision.
- Microsoft’s transparency program — publishing CSAF and VEX attestations for Azure Linux and committing to expand mappings — is documented in MSRC outreach and blog posts about machine‑readable VEX/CSAF rollout. That explains Microsoft’s product‑attestation language and why Azure Linux was specifically named.
- Multiple independent advisory aggregators (OSV, security trackers) reproduce the CVE description and note the upstream patch location, giving additional corroboration.
When multiple independent, authoritative sources converge on the same technical summary — upstream commit, stable tree inclusion, NVD/OSV aggregation, and vendor product attestation — we can be confident about the defect description and the recommended developer/distributor actions.
Practical guidance for administrators and developers
If you operate Azure Linux images, Microsoft’s attestation means you should treat those images as in‑scope and apply vendor updates without delay. If you operate other Microsoft‑supplied artifacts or self‑managed images, follow these steps to confirm exposure and patch:
- Inventory kernel images and modules
- Check running kernel config for IVSC/MEI: inspect /boot/config-$(uname -r) or the output of zgrep CONFIG_INTEL_MEI_VSC /proc/config.gz (when available). If CONFIG_INTEL_MEI_VSC or CONFIG_INTEL_MEI_VSC_HW is set (y/m), the kernel likely contains the mei‑vsc transport.
- Check for present modules
- Look for mei‑vsc, mei‑vsc‑hw, or related modules in lsmod/ modinfo and /lib/modules/$(uname -r)/drivers/misc/mei. If the module exists and is loaded, trtially vulnerable until patched.
- Patch strategy
- For Azure Linux: apply the package or kernel update Microsoft publishes in its CSAF/VEX guidance for this CVE.
- For other distributions: obtain a kernel with the upstream fix (stable kernel update or distribution kernel rebuild including the stable patch) and deploy across affected hosts. Upstream stable commits show where the patch landed for maintainers to pull.
- For WSL2 users and hosts
- Confirm the WSL2 kernel binary and its source tag; if a WSL2 kernel build uses a tag that falls within the vulnerable commit range and built with CONFIG_INTEL_MEI_VSC, install a patched WSL2 kernel or wait for an updated WSL2 kernel release from Microsoft.
- Detection and logging
- Look for kernel oopses, KASAN reports, or shutdown crashes referencing mei_cl_set_disconnected or KASAN slab‑use‑after‑free traces similar to those in the NVD entry. These are strong indicators a host executed the vulnerable shutdown path.
Mitigations if you cannot immediately patch
- Temporarily unloading or blacklisting the mei‑vsc module can prevent the IVSC transport from being loaded, removing the vulnerable code path from the running kernel — but note that this may break device functionality that depends on the IVSC transport and may not be possible for kernels built with the driver built‑in (not modular).
- For containerized or cloud workloads, prefer redeploying new nodes with patched kernels rather than live patching kernel code; live kernel patching solutions are limited in scope and may not cover this particular code path safely.
- Isolate privileged local users: because exploitability sequence may require local actions or the ability to manipulate device teardown, preserving strong local access controls reduces risk during the remediation window.
Supply‑chain and disclosure context
Microsoft’s cadence of publishing CSAF/VEX attestations for Azure Linux improves clarity for Azure Linux customers — it allows automation and deterministic mapping between CVE identifiers and Microsoft product artifacts. That rollout began in October 2025 and Microsoft has repeatedly stated it will update CVE/VEX mappings if additional products are identified as carriers. That policy is why the MSRC advisory names Azure Linux but also why the advisory text must not be read as an exclusivity guarantee for all Microsoft products. In other words:
Azure Linux is the product Microsoft has attesmust be verified per artifact.
WindowsForum and other vendor analyses have repeatedly observed this practical dynamic: vendor attestations focused on one product are operationally helpful but do not obviate the need for per‑artifact verification across an organization’s fleet. Treat absence of attestation as “unknown” not “not affected.”
Risk summary and recommendations — an executive checklist
- Risk: CVE‑2025‑39711 is a use‑after‑free in the IVSC/MEI transport that can cause shutdown crashes and, depending on circumstances, may present escalation risk. Exploitation likely requires local conditions and the presence of the mei‑vsc transport.
- Confirmed product hit: Azure Linux — Microsoft has attested that Azure Linux includes the upstream component and is therefore potentially affected; apply vendor updates.
- Potential additional carriers: WSL2 kernels, linux‑azure kernels, Azure Marketplace images, AKS node images, and any Microsoft‑distributed kernel build could include the IVSC code depending on build options and kernel version. Verify per artifact.
- Immediate actions for operators
- Patch Azure Linux images per Microsoft guidance.
- Inventory other Microsoft‑provided images and WSL2 kernel binaries for CONFIG_INTEL_MEI_VSC / mei‑vsc module presence.
- If a host is found to include the module and cannot be patched immediately, consider blacklisting the module or rebuilding images with the patched kernel.
- Subscribe to MSRC CSAF/VEX feeds and vendor advisories so future attestations reduce uncertainty.
Conclusion
CVE‑2025‑39711 is a real kernel use‑after‑free that upstream maintainers have fixed and that Microsoft has mapped explicitly to
Azure Linux in its CSAF/VEX roll‑out. That Microsoft attestation is authoritative for Azure Linux customers and should prompt immediate patching where Azure Linux is deployed. However, it is not a blanket statement that other Microsoft products are unaffected — the presence of upstream IVSC/MEI code is an artifact‑level property tied to kernel version and build configuration. Operators using Microsoft‑distributed kernels or images (including WSL2, Marketplace or AKS images) must inventory and verify those artifacts and apply patched kernels where necessary. The safest course: patch confirmed carriers, inventory every kernel artifact, and use machine‑readable VEX/CSAF attestations and vendor metadata to reduce uncertainty as Microsoft expands its attestations.
Source: MSRC
Security Update Guide - Microsoft Security Response Center