CVE-2025-37977: Exynos UFS Cache Bug Fixed in Linux Kernel

The Linux kernel patch tracked as CVE-2025-37977 fixes a subtle but important UFS (Universal Flash Storage) configuration bug in the Exynos UFS host driver: when the device tree omits the dma-coherent property, descriptors are treated as non-cacheable but the IOC (I/O cache controller) shareability bits were left enabled — an incompatible configuration that can produce random cache-related stability issues and hangs. This vulnerability is a configuration/compatibility bug rather than a classic privilege‑escalation exploit, but it can cause system instability and availability loss on affected kernels.

Background / Overview​

The problem is rooted in hardware coherency assumptions the Exynos UFS driver makes when interpreting device-tree properties. On SoCs where the UFS DMA regions are not cache‑coherent by default, drivers must clear IOC shareability flags so that the memory controller and device accesses honor the actual cacheability of descriptor memory. If the kernel leaves those shareability bits set while descriptors are non‑cacheable, the result is subtle misbehavior: stale data in caches, ordering mismatches, and hard‑to‑reproduce stability problems affecting UFS I/O. The Linux kernel maintainers accepted fixes for the Exynos driver in the 6.12 and later stable lines; the change set touches drivers/ufs/host/ufs-exynos.* and related headers.
This CVE was published by the Linux CNA and appears in mainstream vulnerability trackers and distribution advisories. Distributions that consume upstream Linux — including the cloud images and kernels used by major vendors — acted to roll or backport the fix into their kernels or published advisories indicating the required kernel levels. Debian, SUSE, and Ubuntu trackers list the problem and the kernel patch references, and stable kernels in the 6.12.x family include the upstream correction.

---

What Microsoft actually said — and what it did not​

Microsoft’s public entry for this CVE (as surfaced through its MSRC CSAF/VEX product attestations) contains an explicit FAQ line that is easily misread: when asked whether “Azure Linux is the only Microsoft product that includes this open‑source library and is therefore potentially affected,” Microsoft’s response describes the company’s attestation policy rather than asserting exclusivity. The text explains that Microsoft keeps the Azure Linux distro up to date, and that MSRC began publishing CSAF/VEX machine‑readable attestations in October 2025. Crucially, Microsoft says it will update the CVE if it identifies impact to additional Microsoft products. That is an important distinction: the bulletin confirms Azure Linux contains the affected kernel code, and Microsoft has attested that fact; it does not claim that no other Microsoft product contains the same code.
Put plainly: Microsoft has attested that the Azure Linux distribution includes the vulnerable component and is therefore potentially affected. That attestation is meaningful and helpful to Azure customers, but it is not a comprehensive, vacuum‑sealed statement that every other Microsoft product has been scanned and declared unaffected. The absence of a VEX statement for some other product is not proof that the product is safe — it is an absence of attestation. Microsoft’s public position is to expand VEX coverage over time and to update CVE entries if more products are found to ship the code.

---

Technical anatomy: why the bug matters​

UFS, descriptors, IOC shareability and dma‑coherent​

• UFS devices use descriptor memory for command/transfer descriptors. The CPU, DMA engine, and the UFS controller can all access that memory region.
• dma-coherent is a device-tree property that indicates those descriptors are located in memory regions that maintain coherence for device and CPU without explicit cache maintenance (flush/invalidate).
• When dma-coherent is absent, the kernel must assume the descriptors are non‑cacheable (or otherwise require explicit cache maintenance), and driver code must avoid setting memory shareability flags that imply coherence.
• The Exynos UFS code previously left IOC shareability bits enabled even when descriptors were non‑cacheable; the patch disables those bits in the dma‑coherent not set case, preventing mismatched assumptions and the resulting stability problems.

Attack model and real‑world impact​

• This is not an elevation‑of‑privilege or remote code‑execution vulnerability in the typical sense. Instead, it creates unreliable I/O behavior and can cause UFS controllers to operate with inconsistent cache semantics.
• The most likely real‑world effects are hangs, data corruption risk (depending on workload and platform), or hard‑to‑diagnose system instability, particularly on devices using Exynos SoCs with UFS storage (e.g., some smartphones, embedded boards, and specialized appliances).
• Exploitation requires either presence on an affected kernel running on impacted hardware or a platform that loads an affected kernel image — in many cases this means local attackers, malformed device trees, misconfigured images, or OEM kernel builds without the fix.

---

Which kernels and distributions were affected — and who fixed it​

Upstream kernel trees accepted changes that address the problem, and the Fix-Pack movement placed the correction into the 6.12 stable family and following releases. The public patch set and release notes for Linux 6.12.26 and subsequent stable cuts include the Exynos UFS change set; a number of distributions have either backported the fix or published advisories telling administrators which kernels are fixed in their images.
Independent trackers (Debian security tracker, SUSE advisories) and downstream vendors (Ubuntu) list the vulnerability and enumerate the specific packages and kernel versions for which fixes or backports are available. If you run a distribution kernel prior to the patched stable kernel versions, you should treat your instance as potentially at risk if it uses Exynos UFS hardware.

---

How to detect whether you are affected​

Detection requires two simple checks: your running kernel version, and whether your system uses the Exynos UFS driver or hardware that relies on the corrected code path.

• Check your kernel version:
• Run uname -r to get the running kernel string.
• Compare against the vendor/Distro advisory or upstream stable kernel releases that include the fix (distributions publish the exact fixed package names). If you are running an older kernel that predates the fix, you may be affected.
• Check whether the driver is present or in use:
• Look at dmesg, kernel logs, or /sys/devices for UFS controller entries that reference ufs-exynos.
• On systems that carry Exynos SoCs (mobile phones, some embedded boards), the presence of drivers/ufs/host/ufs-exynos is a strong indicator that the patched path is relevant.
• If you cannot determine hardware exposure easily, treat kernels that predate the fix as potentially vulnerable on systems with Exynos or vendor kernels derived from older sources. Distribution advisories (Debian, Ubuntu, SUSE) list the precise kernel package levels where vendors backported the fix.

---

What Microsoft’s wording means for Azure customers — practical interpretation​

Microsoft’s MSRC attestation for this CVE says Azure Linux contains the affected open‑source component and therefore Azure Linux images are potentially affected. Microsoft’s action here is twofold and should be read carefully:

• Product‑scoped attestation: The company explicitly confirmed that a named product family — Azure Linux — contains the vulnerable code and published a CSAF/VEX attestation describing that inventory position. That is a helpful, machine‑readable signal for customers who consume Azure Linux images.
• Not a universal exclusion: Microsoft did not declare that no other Microsoft products include the code. Instead, Microsoft committed to "update the CVE to reflect this" if additional products are later identified. In other words, the attestation is a positive confirmation for Azure Linux and an open posture for other products pending further inventory and VEX coverage. Absence of mention for a product ≠ absence of the code.

This distinction matters to enterprise teams that consume multiple Microsoft artifacts: Azure VM images are one thing; Microsoft‑distributed kernels embedded in other products or specialized appliances could still ship the same upstream kernel code. Customers should not assume that because Azure Linux was called out, other Microsoft distributions (or surface areas) are safe by default.

---

Recommended actions for administrators and OEMs​

If you manage Linux systems, especially those built on or near the hardware/software stacks that might include Exynos UFS, follow a prioritized set of actions:

• Inventory first
• Identify hosts running the Azure Linux distribution or vendor kernels. Use package inventories and cloud image metadata to tag Azure Linux images.
• Record kernel versions across your fleet (uname -r + package manager queries) and flag kernels that predate the fixed stable releases.
• Confirm hardware exposure
• For bare‑metal or embedded devices, identify whether the hardware uses Exynos SoCs or UFS controllers that map to drivers/ufs/host/ufs-exynos.
• On cloud images without Exynos hardware, the driver may be present but unused; the risk is primarily on platforms with actual Exynos UFS devices.
• Patch or mitigate
• Apply vendor kernel updates or backports that include the Exynos UFS fix. Many distributions released advisory notes with exact packages; consult your distro security tracker.
• If immediate patching is impossible, limit exposure by isolating affected hosts from untrusted workloads and scheduling maintenance windows for kernel upgrades.
• Validate after upgrade
• Reboot into the patched kernel and verify dmesg for errors related to UFS.
• Run representative I/O workloads to ensure stability and monitor for unusual UFS errors or device resets.
• Monitor VEX/CSAF feeds
• Azure Linux customers should consume Microsoft’s CSAF/VEX attestations to automate inventory matching; Microsoft has said it began publishing such attestations in October 2025 and will expand coverage. However, absence of a VEX entry for other products is not a safety guarantee — maintain your own artifact inventory.

---

For Azure Linux customers specifically​

Azure Linux customers benefit from Microsoft’s product‑level attestation and the company’s intent to keep Azure Linux images up to date. Because MSRC published a VEX entry that specifically lists Azure Linux as shipping the affected component, Azure customers can use that attestation to automate detection and remediation workflows inside Azure governance and vulnerability‑management pipelines. Microsoft has committed to update CVE pages if more Microsoft products are identified as shipping the same code, which is a positive governance signal for cloud consumers.
However, customers should still:

• Validate that the specific Azure image or scale‑set kernel they run uses the patched kernel package.
• Keep an eye on Azure image update notifications and apply updated images or kernels as part of regular maintenance.
• Use CSAF/VEX attestation data as one source in an overall asset inventory rather than the sole source of truth.

---

Why vendor attestations are useful — and where they fall short​

Attestations such as CSAF/VEX are valuable because they provide machine‑readable, vendor‑issued inventory data that can be integrated into automated tooling. Microsoft’s October 2025 rollout of product‑level VEX output is an industry‑positive step: it enables large cloud customers to quickly determine whether a vendor‑shipped product contains specific upstream components, reducing manual triage time.
But there are limitations that every security team must account for:

• Attestations are scoped: an attestation for Product A does not automatically cover Product B, even within the same vendor.
• Attestations depend on vendor inventory completeness and the cadence for generating VEX documents. A vendor may discover new affected artifacts later and will update VEX or the CVE entry accordingly — which is precisely what Microsoft explicitly promised for these Linux CNAs.

---

Risk assessment: who should care most​

• Device manufacturers and embedded Linux integrators that use Exynos SoCs and UFS storage are at highest risk, because the code path is only relevant where the hardware and device tree configurations match the problematic combination.
• Cloud customers running generic Azure Linux images on virtual hardware that does not include Exynos UFS controllers are less likely to be directly impacted, but Azure customers should still confirm the explicit image and kernel package in use.
• Enterprises that maintain fleets of mixed vendor kernels (custom OEM images, vendor‑supplied kernels, or self‑built kernels) should treat this as a standard kernel‑update CVE: confirm presence, patch where necessary, and monitor for related kernel bugs.

---

Responsible disclosure and supply‑chain transparency: the bigger picture​

This CVE and Microsoft’s handling illustrate an important trend: software supply‑chain transparency is moving from ad‑hoc advisories to automated, machine‑readable attestations. Microsoft’s explicit statement that Azure Linux contains the component and the publication of VEX data gives Azure customers immediate, actionable information — while also clarifying that the absence of attestations for other products is not a negative proof. Other vendors and distributions are following similar practices, publishing CVE mappings, kernel advisories, and CVE trackers.
From a governance perspective, the correct approach for enterprise defenders is to:

• Combine vendor attestations with internal artifact scanning,
• Automate matching between VEX/CSAF outputs and real‑world deployed artifacts, and
• Maintain remediation priorities keyed to a materiality model (hardware exposure, exploitability, and business risk).

---

Short checklist — what to do right now​

• Inventory: run uname -r across your fleet and collate kernel package versions. (Prioritize devices with Exynos or UFS hardware.)
• Verify: check /sys and dmesg for ufs-exynos or other UFS controller entries.
• Patch: upgrade to vendor kernels that include the upstream fix (distributor advisories list the patched package names).
• Validate: reboot into patched kernels, test I/O workloads, watch logs for UFS errors.
• Automate: ingest MSRC CSAF/VEX attestations for Azure Linux into your vuln management system, but do not rely on VEX as the only source.

---

Conclusion​

CVE‑2025‑37977 is a pragmatic stability and configuration fix to Exynos UFS handling in the Linux kernel. It can cause serious availability and reliability problems on affected platforms and therefore merits prompt attention from anyone running Exynos‑based hardware or vendor kernels that predate the upstream fix. Microsoft’s public messaging confirms that Azure Linux has been found to include the affected code and that Microsoft publishes CSAF/VEX attestations to help customers automate detection. That confirmation is helpful — but it is not an exclusivity claim. Other Microsoft products could still ship the same upstream code; Microsoft has pledged to update CVE attestations if that occurs. In short: use VEX data where available, but do your own inventory, apply vendor patches, and treat vendor attestations as an important signal in a broader, defense‑in‑depth vulnerability management program.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center