Microsoft’s concise MSRC wording that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate for the product family it names — but it is a product‑scoped attestation, not a categorical guarantee that no other Microsoft product can include the same vulnerable Linux kernel code. ps://www.microsoft.com/en-us/msrc/blog/2025/10/toward-greater-transparency-machine-readable-vulnerability-exploitability-xchange-for-azure-linux)
CVE‑2025‑39788 is a Linux kernel fix described upstream as scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPE. The bug is a correctness/UBSAN issue in the Exynos UFS host driver: on platforms such as Google’s gs101 the UTP transfer request slot count (nutrs) can be 32, and a left‑hand shift written as 1 << nutrs on a plain int produces undefined behavior when nutrs == 32. The upstream change replaces that pattern with the BIT() macro so the value written to the UTRL_NEXUS_TYPE register is correctly typed and no longer subject to shift‑out‑of‑bounds behaviour.
Microsoft’s public FAQ language that you quoted — the paragraph explaining that Azure Linux includes the implicated open‑source library and that Microsoft began publishing CSAF/VEX attestations in October 2025 — is a clear operational statement about Azure Linux. Microsoft has also said it will update CVE records and Vf additional Microsoft products are found to include the same component. That promise is an important transparency commitment, but it does not by itself prove that other Microsoft artifacts are free of the code in question.
This article explains what that MSRC wording means in practice, why the short answer to your question is “No — not necessarily”, and gives practical hunting and mitigation steps for administrators who need to know whether their Microsoft‑supplied kernel or image is affected.
If you manage Microsoft‑provided Linux artifacts, follow the practical verification steps above: inventory, map kernel versions to upstream commits, search for the file or the fixed pattern, and apply vendor patches. Microsoft’s move to publish VEX/CSAF data and to update CVE mappings when additional products are identified is an important step forward — but until every product has been checked, absence of an attestation is not proof of absence.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE‑2025‑39788 is a Linux kernel fix described upstream as scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPE. The bug is a correctness/UBSAN issue in the Exynos UFS host driver: on platforms such as Google’s gs101 the UTP transfer request slot count (nutrs) can be 32, and a left‑hand shift written as 1 << nutrs on a plain int produces undefined behavior when nutrs == 32. The upstream change replaces that pattern with the BIT() macro so the value written to the UTRL_NEXUS_TYPE register is correctly typed and no longer subject to shift‑out‑of‑bounds behaviour.Microsoft’s public FAQ language that you quoted — the paragraph explaining that Azure Linux includes the implicated open‑source library and that Microsoft began publishing CSAF/VEX attestations in October 2025 — is a clear operational statement about Azure Linux. Microsoft has also said it will update CVE records and Vf additional Microsoft products are found to include the same component. That promise is an important transparency commitment, but it does not by itself prove that other Microsoft artifacts are free of the code in question.
This article explains what that MSRC wording means in practice, why the short answer to your question is “No — not necessarily”, and gives practical hunting and mitigation steps for administrators who need to know whether their Microsoft‑supplied kernel or image is affected.
What Microsoft actually said — and what it doesn’t
The attestation model: Azure Linux = inspected and mapped
Microsoft’s CSAF/VEX program produces product‑level attestations: a statement that a named product family was checked and a given upstream component was found inside the artifacts Microsoft ships. When MSRC writes “Azure Linux includes this open‑source library and is therefore potentially affected,” it is saying the Azure Linux distribution (the kernels and packages Microsoft produces for that distro family) cupstream driver code and should be treated as in‑scope for remediation. That is an authoritative, actionable inventory signal for customers running Azure Linux.What the wording does not imply
- It does not state that Microsoft has scanned every Microsoft product, kernel build, or image and certified them not to contain the same upstream file or commit range.
- It is not a technical proof of exclusivity: many Microsoft artifacts are built from upstream Linux sources, and whether they include a given upstream commit depends on kernel version, backports, and build configuration.
- Absence of a VEX/CSAF attestation for some other Microsoft product is absence of attestation, not evidence that the other product is safe.
Why Azure Linux attestation is carefully scoped (the technical reasons)
Several concrete technical realities make the presence of upstream kernel code an artifact‑level property rather than a universal company‑wide fact:- Kernel version and commit range: two kernels built from different upstream versions may or may not contain the commit that introduced — or later fixed — the vulnerable code. The vulnerable pattern in CVE‑2025‑39788 existed in certain upstream versions and was corrected by a specific patch that was backported into many stable trees; whether your device is affected depends on which upstream revision or stable backport your binary includes.
- Vendor backports and patches: large vendors commonly backport security and bug fixes into older kernel branches or apply vendor-specific patches. A Microsoft kernel bud a backported fix (or a backported vulnerable pattern) even if the upstream stable tree shows a different state. This is why per‑artifact verification is required.
- Kernel config (CONFIG_*) choices and module selection: some drivers are compiled in only when specific kernel configuration options are enabled. A Microsoft product that ships Linux kernel artifacts might exclude the UFS host driver entirely (or compile it as a module that's not shipped), in which case that artifact wouldn’t expose the vulnerability — while another Microsoft artifact may include it.
- Embedded/SoC specifics: the Exynos UFS behaviour described in the CVE (nutrs == 32 on gs101) is platform specific. Existence of the driver does not automatically imply exploitability on every platform; the register being programmed incorrectly is meaningful only where the hardware and slot count combine to make the out‑of‑bounds shift manifest as an incorrect register value. Upstream descriptions and the patch notes make these platform conditions explicit.
Technical deep dive: what CVE‑2025‑39788 actually fixes
The bug, in plain terms
The driver code attempted to produce a mask by shifting a 1 left by the number of UTP transfer request slots (nutrs). On a 32‑bit int, shifting by 32 is undefined behavior. On platforms where nutrs == 32 (for example Google gs101), the left‑hand shift was performed on a plain int and produced an incorrect 0 value, meaning the driver wrote the wrong mask into the UTRL_NEXUS_TYPE register. The fix replaces the naive shift with a typed macro (BIT()) which ensures the constant is promoted to an appropriately wide unsigned type before shifting, yielding the intended 0xffffffff mask when nutrs==32. This also silences UBSAN shift‑out‑of‑bounds warnings.Severity and exploitability
Multiple downstream trackers and vendors have recorded this as a correctness and potential robustness issue. The immediate practical impact is an incorrect register programming on affected platforms; the published references show the patch was propagated into stable branches and vendor advisories. Public scoring varies across trackers; some tools show a high CVSS v3.x score summary, but exploitability in the wild is not reported and the bug is primarily a register‑programming correctness/UBSAN fix rather than a clear remote code‑execution zero day. Administrators should assume a correctness bug with potential hardware‑specific consequences and patch accordingly.Cross‑referencing the record: verifying the upstream fix and vendor statements
Independent confirmation of the vulnerability and fix is available from several sources:- The NVD entry and multiple CVE trackers summarize the defect and the fix.
- The upstream kernel commits and stable‑tree merges show the specific patch replacing the naive shift with BIT() and the patch was merged into several stable branches. Stable commit notices (stable‑commits archives) confirm the patch was applied to 5.10 and 5.15 stable trees.
- Distribution and vendor trackers (for example Red Hat’s bugzilla and various CVE aggregators) list the CVE and reference the upstream corrections and their inclusion into vendor updates.
- Microsoft’s public posture —nd the October 2025 VEX/CSAF rollout — is consistent across multiple MSRC CVE pages: Microsoft is explicitly attesting Azure Linux first and promising to add additional product mappings if discovered. That programmatic approach is documented in Microsoft’s MSRC blog announcing VEX adoption.
Short, direct answer to the user’s question
No — Azure Linux is not necessarily the only Microsoft product that includes the affected open‑source library for CVE‑2025‑39788. Microsoft’s statement is a product‑level attestation: Azure Linux has been inventoried and found to include the upstream component, and Microsoft will update CVE/VEX records if other products are discovered to include it. Absence of attestations or public mention for other Microsoft products should be read as not yet attested, not as proven absent.Who else inside Microsoft could include the same code?
- WSL2 kernels published by Microsoft on GitHub or kernels used in Windows Subsystem for Linux images. The WSL2 kernel is a curated Microsoft build of a Linux kernel and often tracks upstream drivers. If the WSL2 kernel build uses the same upstream commit range and includes the Exynos UFS driver, it could carry the same code path.
- Other cloud images, appliance images, Marketplace virtual machine images, or product‑specific kernels used to support Azure services and specialized hardware emulation. If these artifacts are compiled from upstream branches that include the unfixed commit or carry vendor backports, they may be affected.
- Microsoft’s other Linux distributions or derivative kernel builds (for example the older CBL‑Mariner lines or any private Linux kernel builds used for device teams). Microsoft acknowledged that Azure Linux was the first product family to receive VEX attestations; the company explicitly committed to expanding attestations to more product families as inventory work continues.
Practical verification steps for administrators (what to do now)
If you operate any Microsoft‑supplied artifacts (Azure VMs using Microsoft images, WSL instances, managed appliances, or kernels shipped by Microsoft), follow these practical steps to discover whether your images include the vulnerable code.- Inventory your Microsoft artifacts:
- Identify which Azure VM images, Marketplace appliances, or Microsoft kernel packages you run.
- Record kernel version strings and kernel package metadata (uname -a; package managers and kernel package versions).
- Map kernel versions to upstream commit ranges:
- Compare the kernel version and vendor build ID to the upstream commit ranges listed in kernel‑level advisories (stable commits and the specific patch commits for CVE‑2025‑39788). If your kernel version predates the backport, assume it could be vulnerable.
- Search for the vulnerable code or the fixed pattern:
- If you can inspect the kernel source or module binaries, search for the relevant file path (drivers/ufs/host/ufs-exynos.c) and the specific masked‑shift code. If you only have binaries, consult package changelogs / vendor release notes.
- Consult Microsoft VEX/CSAF attestations and CVE pages:
- Check the MSRC CVE entry for the CVE ID you care about (MSRC’s published VEX/CSAF files for Azure Linux will show “Known Affected”, “Fixed”, or similar statuses). Remember: Azure Linux being listed is authoritative for Azure Linux; if other product families are not listed, they may simply be not yet checked.
- Patch and update:
- Apply vendor or distribution kernel updates that include the stable backport of the patch.
- For environments that cannot be patched immediately, enforce compensating controls (disable access to affected hardware paths, restrict use of UFS devices where possible, or use alternate images).
- Record and monitor:
- Track Microsoft CVE updates — MSRC will amend the CVE/VEX mapping if additional Microsoft products are identified as carriers.
Mitigation and remediation guidance
- Apply updated kernels: the authoritative remediation is to upgrade to kernels that include the upstream patch. The upstream commits were merged into various stable trees and distributions are shipping packages; ensure your distribution kernel packages include the stable patch. (spinics.net)
- Where immediate patching is infeasible: isolate affected hardware paths and limit untrusted code execution on VMs that might access vulnerable device drivers.
- For WSL users: if you rely on the Microsoft‑provided WSL2 kernel, check the kernel version of your WSL instance. Microsoft publishes WSL kernel releasese your WSL kernel is updated when Microsoft releases a fixed build.
- For cloud tenants running Marketplace images: prefer vendor images with recent kernel packages; apply vendor updates and redeploy patched images where possible.
Strengths and shortcomings of Microsoft’s approach
Notable strengths
- Transparency push: Microsoft’s adoption of machine‑readable CSAF/VEX attestations and the public MSRC blog explaining the program is a meaningful step toward clearer supply‑chain communication. Publishing VEX files for Azure Linux creates an authoritative, automated signal for customers who run those images.
- Product‑scoped clarity: Telling customers explicitly which product family was inventory‑checked reduces uncertainty for the largest immediate target set — Azure Linux customers can treat that attestation as actionable.
- Commitment to expand: Microsoft’s explicit promise to expand attestations if other products are identified demonstrates a process intent to reduce the “unknowns” over time.
Potential risks and limitations
- Inventory incompleteness: A product‑scoped attestation necessarily leaves a coverage gap across other artifacts. Organizations that rely solely on the presence/absence of MSRC attestations for enterprise risk decisions may misjudge exposure unless they perform artifact‑specific checks.
- Backport complexity: Microsoft and other vendors often backport fixes or change code independently of simple upstream version numbers. That means a given kernel version number alone may not be a reliable proxy for whether a specific change is present — precise mapping to commit hashes or package changelogs is necessary.
- Operational latency: VEX/CSAF is powerful, but only as fast as inventory and verification processes. There will always be a non‑zero window between public disclosure, vendor inventories, and the day every product family is attested and patched.
Recommended policy and operational changes for enterprises
- Treat vendor VEX/CSAF attestations as high‑value signals, but not as the sole source of truth. Combine vendor attestations with internal artifact inventories, SBOMs, and direct binary/source verification.
- Automate mapping from vendor CVEs and VEX files into youstems so product‑attested vulnerabilities create immediate remediation tickets for in‑scope assets.
- For Microsoft artifacts in particular, add explicit checks in your change control that verify:
- Which kernel version & build ID your Azure VM, Marketplace appliance, or WSL image uses.
- Whether that build has MSRC or upstream vendor release notes listing the CVE as fixed or affected.
- Maintain a small team or runbooks for rapid binary or source inspections of kernel modules and drivers — these are fast checks that often resolve the “is it present?” question more reliably than version‑number heuristics.
Conclusion
Microsoft’s MSRC statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is correct and valuable: it is an authoritative inventory attestation for the Azure Linux family and a clear instruction for customers running those images to treat the CVE as in‑scope. However, that precise wording should not be read as an exhaustive claim that no other Microsoft product can ever contain the same vulnerable code. Kernel artifacts are built, backported, configured, and published in many forms across a large company; whether a given Microsoft product is affected depends on per‑artifact factors such as kernel version, backports, and CONFIG choices. Administrators should therefore treat the Azure Linux attestation as an authoritative “yes” for Azure Linux but continue to exercise artifact‑level verification and patching across all Microsoft‑supplied images they run.If you manage Microsoft‑provided Linux artifacts, follow the practical verification steps above: inventory, map kernel versions to upstream commits, search for the file or the fixed pattern, and apply vendor patches. Microsoft’s move to publish VEX/CSAF data and to update CVE mappings when additional products are identified is an important step forward — but until every product has been checked, absence of an attestation is not proof of absence.
Source: MSRC Security Update Guide - Microsoft Security Response Center
