The concise answer is:
No — Azure Linux is the only Microsoft product that Microsoft has publicly attested as including the implicated upstream component for CVE‑2025‑39790, but that attestation is product‑scoped and time‑boxed; it does not prove that other Microsoft artifacts cannot contain the same vulnerable Linux kernel code. Treat Azure Linux as a confirmed carrier and act on that immediately, but do not assume other Microsoft‑distributed kernels (WSL2, Marketplace images, linux‑azure kernels, custom VM images, container hosts) are automatically safe — each artifact requires per‑build verification or a future Microsoft VEX/CSAF update to clear it.
Background / Overview
CVE‑2025‑39790 is a recently published Linux kernel vulnerability that lives in the MHI host code path:
bus: mhi: host: Detect events pointing to unexpected TREs. In plain terms, the bug arises when the host processes a completion/event from a remote MHI device and the event points to a Transfer Request Element (TRE) the host doesn’t expect. Under certain timing and synchronization conditions this can allow the host to process stale or freed data, leading to a
double‑free or similar memory safety failure — a classic kernel stability/security problem. The NVD description and upstream kernel explanations make the failure mode and the triggering race conditions explicit.
This class of defect is not a benign logic quirk: it can produce crashes, null dereferences, and potential memory corruption with consequential risk to kernel integrity. Upstream kernel maintainers issued stable‑branch fixes and defensive checks in the MHI host/endpoint code to detect and reject events that point to unexpected TREs — the corrective changes are visible in the kernel patch stream and referenced in vendor advisories.
Why this matters to Microsoft customers is twofold. First, Microsoft’s MSRC team used the CSAF/VEX machine‑readable format to
attest that Azure Linux includes the implicated open‑source component and is therefore potentially affected; that gives Azure Linux customers an authoritative, automatable signal to prioritize remediation. Second, Microsoft explicitly stated that it will update the CVE/VEX records if additional Microsoft products are found to carry the same code — leaving open the possibility that other Microsoft artifacts could later be attested as in‑scope.
What Microsoft actually said — parsing the MSRC wording
Microsoft’s language for this class of kernel CVEs follows a clear pattern:
- They confirm where their inventory work has found a specific upstream open‑source component inside a Microsoft product (e.g., “Azure Linux includes this open‑source library and is therefore potentially affected”).
- They explain that they began publishing machine‑readable CSAF/VEX attestations in October 2025 and that additional products will be added to the attestation set once inventories are complete.
Two critical points follow from that phrasing:
- The attestation is an authoritative confirmation for the attested product (Azure Linux in this case). If you run an Azure Linux image, treat that product as in‑scope and follow Microsoft’s remediation guidance.
- The attestation is not a categorical statement about every Microsoft product. The absence of an attestation for another Microsoft artifact is absence of attestation — not proof of absence of the vulnerable code. Microsoft’s inventory project is phased; other product families may be added later as the VEX/CSAF work completes.
The technical reality: why the same upstream code can show up in multiple Microsoft artifacts
Large vendors like Microsoft ship many different Linux kernel artifacts. Each artifact is a separate build of the upstream kernel with its own:
- kernel version and upstream commit range,
- kernel .config (which modules are compiled in or built as modules),
- selective vendor backports or local patches,
- packaging choices for images (full kernel package, Marketplace image, container host).
Because of these per‑artifact differences, the exact presence (or absence) of a vulnerable upstream function is an artifact‑level property. In practical terms, that means the same MHI host code that was fixed upstream could appear in some Microsoft‑distributed kernels but not others depending on those build variables. The vendor attestation for Azure Linux confirms that Azure Linux contains the affected code in the builds Microsoft inspected; it does not automatically exclude other kernel artifacts Microsoft ships, such as WSL2 kernels, linux‑azure kernels used by particular VM SKUs, Marketplace VM images, or custom container host images.
Evidence and cross‑checks
To validate the bug description, scope, and vendor messaging we cross‑checked multiple independent sources:
- The NVD entry gives the canonical CVE description and the memory‑safety double‑free explanation for the MHI host event handling issue. It also lists affected commits and the general fix approach.
- Upstream Linux kernel mailing list posts and patch threads discuss the exact race condition: an event ring element can point to a TRE that is ahead of the host’s read pointer unless the host/device synchronization rules are correctly enforced, and that can expose the host to stale or freed data — the rationale behind the defensive checks added to the host code.
- Vendor downstream advisories (for example, SUSE and Amazon’s ALAS tracking) include the same patch text in their kernel updates and list the fix in their security bulletins — independent confirmation that the upstream fix has been propagated into distribution kernels.
- Microsoft’s own public VEX/CSAF rollout blog explains the phased inventory approach that produced the Azure Linux attestation and the promise to expand attestations in time — the authoritative source for Microsoft’s product mapping and how to interpret it.
Taken together, these sources corroborate both the technical root cause of CVE‑2025‑39790 and Microsoft’s product‑attestation approach.
Operational implications — what Azure Linux customers must do now
If you run Azure Linux images, treat the VEX attestation as authoritative and remediate without delay. Practical, immediate actions:
- Identify affected systems:
- Inventory Azure Linux hosts and nodes in your environment (VMs, AKS node pools, container hosts).
- For each system, capture kernel version and module presence: uname -r; lsmod | grep mhi; modinfo mhi (or equivalent). These checks verify whether the MHI driver is present in your runtime kernel. (If MHI is absent — for example, on VM types that never ship MHI support — the runtime exposure is nil.)
- Apply Microsoft’s updates:
- Use Microsoft’s published kernel images and distribution updates for Azure Linux. The VEX attestation exists precisely so automation platforms can prioritize and remediate those images quickly. Patch and reboot according to your change control windows.
- Compensating controls where patches are delayed:
- Restrict who can access device nodes tied to MHI (if applicable).
- Segment or isolate workloads on hosts running kernels with the vulnerable code.
- Avoid running untrusted guests/containers on hosts that expose MHI device files to untrusted code.
- Document and log:
- Record which Azure Linux images were patched and when, so future audits can demonstrate coverage.
These steps are standard operational hygiene for kernel‑level vulnerabilities and flow directly from the attestation — Microsoft has told you that Azure Linux contains the component and so Azure Linux systems are the first, highest‑priority intervention point.
What defenders must not assume
- Do not assume that an absence of a Microsoft VEX/CSAF entry for another product guarantees it’s safe. Microsoft’s VEX rollout began with Azure Linux; the company committed to updating records as inventories progress. That leaves other Microsoft artifacts in an unverified state until explicitly attested. Treat un‑attested artifacts as unknowns, not negatives.
- Do not assume all Linux kernel CVEs only affect “consumer” or “embedded” hosts. The same upstream source code appears in cloud kernels, WSL kernels, and purpose‑built VM images — all of which may be present in enterprise estates. A measured inventory is necessary.
- Do not rely on vague claims of “we don’t ship that hardware” without verifying the actual kernel artifacts and module lists in your specific image builds. The decision boundary is artifact‑level, not marketing‑product‑level.
Practical verification checklist (artifact‑level checks you can run today)
- On each host image you manage (Azure Linux, WSL2 kernels you ship internally, private Marketplace images, container host images), run:
- uname -a — record the kernel version and build string.
- lsmod | grep -i mhi — does the MHI host driver appear as a module?
- grep -I "drivers/bus/mhi" -R /lib/modules/$(uname -r) — search installed module paths for MHI sources or object files.
- For WSL2 or custom kernels, check the kernel .config used for the build if you can (config file in /proc/config.gz or /boot/config-*). Look for CONFIG_MHI or related flags. If MHI is not compiled in, the runtime exposure is nil.
- Map the kernel build to upstream commits where possible:
- If your kernel package includes a packaged changelog or stable‑commit list, compare those commits with the upstream fixes referenced by NVD / linux‑cve threads. This tells you whether your build contains the vulnerable commit range or the fix.
These checks turn the abstract question “could another Microsoft product be affected?” into a concrete artifact inspection problem that your security/ops teams can automate and track.
Risk analysis — balancing attacker value and real‑world exposure
From a technical standpoint, the MHI host TRE bug is dangerous because it can lead to memory corruption in kernel context — a stepping stone to privilege escalation, persistent denial of service, or targeted exploitation in a high‑value environment. That said, exploitation prerequisites matter:
- The vulnerable code path is reachable only when an MHI device is present and actively interacting with the host ring buffers. Many cloud VM types and generic virtualized instances do not present MHI devices to guests by default. That reduces the blast radius for VMs that are purely virtual and do not attach physical MHI hardware.
- Conversely, environments that use commodity or OEM modules (modems, cellular modem bridges, wireless SoC interfaces) are more likely to load and use the MHI driver and so have higher exposure. Those system owners must prioritize fixes.
- Attack complexity: exploiting a race and double‑free in kernel space often requires precise timing or a local privileged context to trigger device‑level events. However, where untrusted code can influence device inputs (for example, in multi‑tenant edge appliances, or in container workloads that are given direct device access) the risk increases materially.
Risk therefore is not binary: it depends on device exposure, kernel build choices, and deployment topology. That is why per‑artifact and per‑deployment verification is the appropriate defense posture rather than a one‑size‑fits‑all assumption.
Why Microsoft’s phased VEX approach is helpful — and where it leaves gaps
Microsoft’s introduction of machine‑readable VEX/CSAF attestations is a step forward: it allows automation platforms to ingest definitive statements about whether a specific Microsoft product contains a particular upstream component. For Azure Linux customers, that’s already useful — VEX gives a clear signal to prioritize patching.
However, there are operational caveats:
- A phased rollout necessarily creates a gap window where only a subset of Microsoft artifacts is attested. During the rollout, security teams must continue to perform artifact verification for un‑attested products rather than waiting for Microsoft to finish inventory.
- VEX/CSAF attestation is only as useful as the granularity of the product mapping. Artifacts that look similar at marketing level (e.g., Azure Marketplace image vs. Azure Linux node image) may be distinct at the kernel artifact level; automation must map artifacts precisely to the VEX product identifiers to avoid false negatives.
In short, VEX improves clarity — but it does not eliminate the operational work of inventory and cross‑checking.
Recommended timeline and playbook for security teams
- Within 24–48 hours:
- Confirm which Azure Linux images you run and apply Microsoft’s Azure Linux kernel updates.
- Update tickets and change windows for planned reboots where required.
- Within one week:
- Run the artifact‑level verification checklist across other Microsoft‑supplied kernels in your estate: WSL2 on developer machines, linux‑azure kernels on VM SKUs, Marketplace images, container host images.
- Produce a vulnerability matrix that maps images to “confirmed vulnerable / confirmed patched / unknown”.
- Within one month:
- Automate the kernel/module checks in your asset inventory system.
- Where patches are not yet available or risk is high, apply compensating controls (isolate hosts, remove device passthrough, restrict device node access).
This operational tempo is realistic and aligns with Microsoft’s attestation cadence: apply the Azure Linux fixes immediately and treat other Microsoft artifacts as unknowns until verified.
Final assessment and transparency note
Microsoft’s public statement — “Azure Linux includes this open‑source library and is therefore potentially affected” — is accurate and actionable for Azure Linux customers. The company’s VEX/CSAF rollout and promise to update attestations if additional Microsoft products are identified is a positive transparency practice. But it must be read precisely:
attested equals confirmed for that product; not attested does not equal proven safe for everything else. Security teams must therefore combine the vendor attestation with their own artifact inventory checks across WSL2, Linux kernels packaged with particular VM SKUs, Marketplace images, and container hosts to produce a defensible risk posture.
One cautionary note: any claim that “Azure Linux is the only Microsoft product that could possibly contain the vulnerable code” is unverifiable at publication time. Microsoft has committed to extend attestations as it completes inventories; until those attestations are published or until you confirm artifacts locally, treat other Microsoft kernels as
potentially in scope and verify them accordingly.
Quick checklist — what to do right now
- If you run Azure Linux: patch now and follow Microsoft’s guidance.
- Inventory kernels across your estate (WSL2, linux‑azure, Marketplace images, custom images): check for MHI module presence and kernel build metadata.
- Automate checks and track remediation status in your vulnerability tracking system.
- Apply compensating controls where immediate patching is impractical.
- Watch Microsoft’s CSAF/VEX feed for updates — Microsoft will update attestations if additional products are found to contain the component.
CVE‑2025‑39790 is a technical kernel defect with a clear upstream fix and clear vendor attestation for Azure Linux. The path forward for defenders is straightforward: patch attested Azure Linux images immediately, inventory other Microsoft artifacts proactively, and automate the verification so that future attestations or fixes can be applied rapidly and with confidence.
Source: MSRC
Security Update Guide - Microsoft Security Response Center