The Linux kernel fix tracked as CVE-2025-37826 corrects a missing NULL check in the UFS SCSI stack (ufshcd_mcq_compl_pending_transfer), and Microsoft’s public advisory notes that
Azure Linux includes the open-source component and is therefore potentially affected — but that wording is a product-scoped attestation, not a categorical claim that
no other Microsoft product can include the same code.
Background / Overview
The vulnerability
- The defect is in the Linux kernel’s UFS SCSI driver code: a call path may dereference a NULL hardware-queue pointer because ufshcd_mcq_req_to_hwq can return NULL; the fix adds an explicit NULL check to avoid a NULL-pointer dereference and crash.
- Upstream kernel maintainers merged the commits that add the guard into the stable trees; distribution vendors have mapped the change into their kernel packages and published fixes.
Why this matters
- The practical impact is availability-oriented: a NULL pointer dereference in kernel space typically causes an oops or panic that can crash or destabilize the host. Attackers wishing to create denial‑of‑service conditions may exploit local access to certain device paths or contrived device interactions; there is no authoritative public indication of a remote, network-triggered RCE for this specific fix.
- The vulnerability was recorded as CVE‑2025‑37826 and has been tracked by NVD and distribution security trackers; vendors such as Debian, Ubuntu and others list fixed package versions or note that particular releases are not affected because the vulnerable code is not present in those builds.
How Microsoft described its exposure
- Microsoft’s MSRC entry for the related CVE states: “Azure Linux includes this open-source library and is therefore potentially affected,” and adds a pledge to publish machine-readable CSAF/VEX attestations and to update the CVE mapping if additional Microsoft products are identified as carriers. That language is procedural and product-scoped: it tells Azure Linux users the company validated that product’s inventory and mapped the upstream component into it.
Is Azure Linux the only Microsoft product that includes the library (short answer)?
No —
not necessarily. Azure Linux is
the only Microsoft product Microsoft has publicly attested to include the implicated kernel component for this CVE at the time of the advisory, but absence of attestations for other Microsoft products is
not proof that those products cannot or do not include the vulnerable code. In practice, other Microsoft-shipped artifacts (WSL2 kernels, Azure marketplace images, custom kernel builds used for managed services, or appliance images) can include the same upstream kernel files depending on build configuration, kernel version, and packaging. Microsoft has stated it will update the CVE/VEX mapping if additional products are found to ship the component.
Why that nuance matters
- A vendor’s VEX/CSAF attestation is an inventory statement for specific product families the vendor has completed scanning. It is not an exhaustive scan of every binary or image the vendor has ever published. Microsoft’s attestation is authoritative for Azure Linux but not an implicit guarantee that WSL kernels, linux-azure kernel builds, Marketplace images, device images, or embedded appliance kernels are free from the same upstream code.
- Kernel components are an artifact-level property: whether a driver is present depends on the kernel configuration (CONFIG options), whether it’s built-in or a module, and whether the particular kernel version contains the vulnerable commit. Different builds can diverge.
Technical verification: how to determine whether your Microsoft-supplied instances are affected
Operators must confirm at the artifact level — a checklist follows for quick verification on running systems and offline images. These are practical commands and checks to determine presence, carriage, and patch status.
On a running Linux host (VM, container host, WSL)
- Verify kernel version:
- uname -r
- Check whether the UFS driver and relevant modules are present:
- modinfo ufs && modinfo ufshcd (if the module is present in /lib/modules)
- lsmod | grep ufs
- Inspect the kernel config for build-time inclusion:
- zgrep CONFIG_UFS /proc/config.gz (or check /boot/config-$(uname -r)
- Look for CONFIG_UFS_FS, CONFIG_SCSI_UFS, or similar options
- Search installed kernel package changelogs for the CVE or for the upstream commit IDs referenced in the kernel-stable commits:
- On Debian/Ubuntu: apt changelog linux-image-$(uname -r) | grep -i 37826
- On RPM-based systems: rpm -q --changelog kernel | grep -i 37826
- If you run WSL2, confirm the WSL kernel config and version (the WSL2 kernel repo contains the config used for builds). If you use a custom WSL kernel, inspect that custom image.
For offline images and published vendor packages
- RPM-based images: rpm -qpl kernel-<package>.rpm | grep -i ufshcd
- Debian/Ubuntu kernels: dpkg -L linux-image-<version> | grep -i ufshcd
- Container images: inspect the kernel package versions in the image or boot a test instance to run the checks above.
- Marketplace or appliance images: treat them as distinct artifacts — confirm the publisher’s update advisories and, where possible, boot the image in an isolated lab to verify.
What to look for
- Presence of drivers: confirm whether the driver source files (drivers/ufs/core/ufshcd.c and related modules) ended up in the compiled kernel.
- Kernel version mapping: check whether your kernel version includes the upstream stable commit(s) that fixed the NULL-check. The kernel CVE announcements and stable commit diffs are authoritative for that mapping.
Cross-referencing the public record (verification with independent sources)
Key claims and their independent corroboration:
- The fix exists upstream and is in the kernel stable trees: corroborated by the kernel stable commits and the linux-cve-announce posting.
- Distributions have mapped and fixed the issue in their kernel packages (or declared not-affected when the code path isn’t present): Debian’s security tracker, Ubuntu advisories, and Amazon Linux pages list affected/fixed package statuses. Use those vendor advisories to find the exact fixed package you must install.
- Microsoft’s public attestation that Azure Linux includes the library and is potentially affected is explicitly documented in MSRC messaging and in Microsoft’s CSAF/VEX rollout documentation — Microsoft has also said it will update the CVE mapping if further products are discovered to carry the component. This means Azure Linux is authoritative for the attestation, and Microsoft will expand coverage as inventory work completes.
When you make remediation decisions, cross‑check at least two independent sources (distribution security trackers and upstream kernel commits; vendor advisories and public CVE trackers) to ensure the package/version mapping and the fix are consistent.
Operational guidance and remediation steps
If a host is identified as
potentially affected (i.e., the kernel build contains the UFS driver and the kernel version precedes the fix), follow this plan:
- Prioritize
- High priority: Multi‑tenant hosts, hypervisors, image scanners, or services that expose UFS device nodes or SCSI device access to untrusted users.
- Medium priority: Single‑tenant hosts that do not expose device access to untrusted users but process external media.
- Patch
- Obtain the vendor’s patched kernel package (distribution kernel update) or apply the vendor-recommended backport.
- Schedule a controlled maintenance window and reboot into the patched kernel.
- Validate
- After reboot, confirm uname -r shows the updated kernel and check kernel logs for absence of the oops/panic signatures previously associated with the vulnerability.
- Confirm the fixed commit or CVE appears in the kernel changelog for the installed package.
- Short-term mitigations if immediate patching is impossible
- Restrict access to device nodes that could exercise the driver (no untrusted containers with access to /dev/ or SCSI/UFS device nodes).
- Harden SELinux/AppArmor/LSM policies and ensure least-privilege for local users and containers.
- Isolate image-processing pipelines and CI runners.
- For cloud customers
- For Azure VM images labelled as Azure Linux, rely on Microsoft’s VEX/CSAF outputs for the product-level mapping and the vendor’s published image updates. For other Microsoft images (Marketplace, WSL, linux-azure), treat each as an individual artifact and verify as described above.
Microsoft’s VEX/CSAF approach — strengths and residual risks
Strengths
- Transparency and automation: Publishing CSAF/VEX attestations for Azure Linux gives customers a machine-readable, vendor-validated signal they can use to automate triage and patch prioritization for that product family. This reduces noisy manual inspection and improves determinism for Azure Linux customers.
- Timely vendor mapping: Microsoft publicly committing to expand mappings if additional products are found to ship the component is a positive operational practice: it signals an intent to iterate and document further exposures.
Residual risks and limitations
- Inventory coverage is phased, not exhaustive: The VEX statement is a validated inventory for the product(s) Microsoft has checked. It does not prove the absence of the component from every Microsoft artifact (WSL kernels, Marketplace images, device partners). Absence of an attestation is typically a time-bound state reflecting incomplete inventory work rather than a categorical absence.
- Artifact drift and build differences: Microsoft and other vendors produce many distinct kernel artifacts with different build configs; a single upstream component can appear in one artifact and be absent in another. That makes per-artifact verification necessary.
- Customer assumptions about management boundaries: Some Azure Marketplace images or vendor-supplied images may have different update responsibilities; customers can mistakenly assume Microsoft will patch all images, but ownership and update responsibilities vary by image publisher. The attestation clarifies Azure Linux but not all marketplace or third-party artifacts.
Critical analysis: what operators and risk managers should take away
- Treat Microsoft’s Azure Linux attestation as authoritative and actionable for any Azure Linux images you run. Use Microsoft’s CSAF/VEX JSON outputs to automate detection and remediation for those images.
- Do not infer exclusivity from that attestation. Any Microsoft‑published or Microsoft‑built kernel artifact (WSL2 kernel, linux‑azure kernel packages, Marketplace or appliance images) can be a possible carrier until you confirm otherwise. This distinction matters because different artifacts have different patch cadences and ownership models.
- Verify at the artifact and host level. Automated inventory (CMDB, configuration management, SBOMs) plus targeted runtime checks (modinfo, /proc/config.gz, kernel package changelogs) are essential to move from possibility to evidence. Use at least two independent sources — upstream commits and your distro/vendor security tracker — when deciding to patch and roll out.
- Where Microsoft’s VEX/CSAF feed does not list a product you run, escalate to the publisher (Microsoft or third-party image provider) and treat the image as “inventory work pending.” Maintain compensating controls until clarity is achieved.
Practical checklist (consolidated)
- Inventory
- Map all hosts and images that run Microsoft-supplied artifacts (Azure VM images, Marketplace images, WSL2 instances, AKS node images).
- Verify
- For each host/image: run uname -r; inspect kernel config for UFS/SCSI options; check for presence of ufshcd or ufs modules.
- Cross-reference kernel package changelogs against the upstream commit IDs that fix CVE‑2025‑37826.
- Patch
- Apply vendor kernel updates, schedule reboots, and validate patched kernels in a test ring before mass rollout.
- Mitigate
- If patching is delayed, restrict device access, isolate image-handling systems, and increase monitoring for kernel oops patterns.
- Automate
- Ingest Microsoft’s CSAF/VEX artifacts for Azure Linux into your vulnerability management system to automate detection and prioritization for Azure Linux images.
Unverifiable claims and caveats
- No public evidence indicates Microsoft has mapped every Microsoft artifact (WSL2 kernels, marketplace appliances, embedded device images). Microsoft’s public line is transparent about intent to expand mappings; however, until Microsoft’s inventory work completes and the VEX/CSAF entries are updated, asserting that no other Microsoft product is affected would be incorrect. Treat that as a gap to be closed by further vendor attestations or by independent artifact inspection.
- Do not assume the presence of a driver in source code means every downstream product is vulnerable — kernel configuration, module inclusion, static linking and backport choices determine real exposure. Conversely, do not assume absence of a public attestation equals absence of risk. Both mistakes are common and costly.
Conclusion — pragmatic posture for Windows and Azure operators
CVE‑2025‑37826 is a kernel robustness fix that must be treated as an availability and stability risk for any Linux kernel build that includes the UFS SCSI driver and predates the upstream fix. Microsoft’s public attestation that
Azure Linux includes the component and is therefore potentially affected is a useful, authoritative signal for operators who run Azure Linux images — take that attestation and act on it. At the same time, do not extend that signal beyond its stated scope: it is a product‑level inventory assertion, not a universal denial of exposure for the rest of Microsoft’s diverse artifact catalog.
Operators should:
- Rely on Microsoft’s VEX/CSAF output for Azure Linux to automate triage for those images.
- Independently verify every other Microsoft-supplied artifact you run (WSL, marketplace images, linux-azure kernels) by checking kernel configs, module presence, and vendor changelogs before assuming they are unaffected.
- Patch promptly, isolate risky artifacts, and use compensating controls where immediate patching is infeasible.
This measured approach — trust the vendor’s attestation where it exists, verify where it does not, and patch with validated packages — will reduce operational risk while avoiding false assurance or unnecessary disruption.
Source: MSRC
Security Update Guide - Microsoft Security Response Center