The Linux kernel maintainers have pushed a critical fix for a stability bug in the Exynos Universal Flash Storage (UFS) driver that could lead to random system hangs, data corruption, and hard-to-diagnose crashes on affected hardware. The vulnerability, tracked as CVE-2025-37977, stems from a misconfiguration in how the driver handles cache coherency when a specific device-tree property is absent. Microsoft has confirmed that its Azure Linux distribution ships the vulnerable code, and multiple other distributions—including Debian, Ubuntu, and SUSE—have released patched kernels. If you run a system with an Exynos SoC or a kernel derived from the upstream code before the fix, immediate action is advisable.

The Bug in Detail

At the heart of CVE-2025-37977 is a subtle mismatch in the Exynos UFS host driver’s handling of DMA (Direct Memory Access) descriptors. UFS devices use descriptor memory for command and transfer operations—a region accessible by the CPU, the DMA engine, and the UFS controller. The device-tree property dma-coherent tells the kernel whether this memory region maintains automatic cache coherence between the device and the CPU. When the property is present, the system guarantees that data seen by both sides is always up to date. When it’s absent—which is the case on many Exynos SoC platforms—the kernel must treat descriptors as non-cacheable and must not enable memory shareability flags that imply coherence.

The Exynos UFS driver, however, was leaving IO Cache Controller (IOC) shareability bits enabled even when dma-coherent was missing. This created an impossible configuration: the driver was telling the hardware that the memory was shared and coherent, while the actual memory attributes said otherwise. The result was unpredictable misbehavior: stale data in CPU caches, ordering mismatches between the UFS controller and the rest of the system, and intermittent I/O failures. In practice, this could manifest as random application hangs, file system errors, or full system stalls—problems that are notoriously difficult to reproduce and debug.

The upstream fix, which landed in the Linux 6.12 stable tree and specific backports, explicitly disables the IOC shareability bits when dma-coherent is not set. This aligns the hardware configuration with the kernel’s expectations and eliminates the mismatch.

Which Systems Are Affected?

The scope of the vulnerability is limited to systems that both run a vulnerable kernel and use the Exynos UFS driver. That means:

  • Smartphones, tablets, and embedded boards with Samsung Exynos SoCs (e.g., certain Galaxy series devices, some Chromebooks, and industrial single-board computers) that rely on UFS storage are directly at risk.
  • Cloud virtual machines using Azure Linux images on non-Exynos hardware may still carry the vulnerable code in their kernels, but the driver is unlikely to load or be active. The risk is therefore lower, though Microsoft has chosen to attest that Azure Linux contains the affected component.
  • Any other Linux distribution that ships a kernel based on the upstream code before the fix—especially if it’s deployed on bare-metal Exynos hardware—should be considered potentially vulnerable.

Microsoft’s Security Response Center (MSRC) has published a Common Security Advisory Framework (CSAF) and Vulnerability Exploitability eXchange (VEX) attestation for this CVE regarding Azure Linux. The attestation states that Azure Linux includes the open-source library with the vulnerability, and Microsoft is committed to keeping its Azure Linux images up to date. Importantly, the MSRC did not claim that no other Microsoft product contains the code; if additional products are found to be affected, Microsoft has said it will update the CVE entry. For now, Azure Linux customers should assume their kernels are affected unless they have applied the specific fix.

How Did We Get Here?

The Exynos UFS driver has been part of the Linux kernel for years, and the offending code likely went unnoticed because it only causes problems on a specific combination of hardware and device-tree configuration. Many devices that use Exynos SoCs may have set dma-coherent correctly, masking the bug. However, for those that don’t, the instability has been a lurking issue.

The vulnerability was disclosed through the Linux kernel CNA (CVE Numbering Authority) and published in mainstream vulnerability trackers. Distributions began backporting or rolling out fixes in the 6.12 stable kernel series. Microsoft’s entry into the advisory, with its explicit confirmation for Azure Linux, came through the company’s new CSAF/VEX program, which started in October 2025. The FAQ on the MSRC page clarifies that the VEX attestation is a positive inventory statement—a way for Microsoft to transparently declare that a specific product ships an open-source component. It is not an exhaustive security audit of all Microsoft products. This distinction has caused some confusion, but the practical takeaway is clear: if you use Azure Linux, patch.

What Should You Do?

For the vast majority of users, the fix is a standard kernel update. Here’s a step-by-step action plan:

1. Check Your Kernel Version

Run uname -r on any Linux system you manage. Compare the version against your distribution’s advisory. Fixed kernels typically include the Exynos UFS patch starting from Linux 6.12.26 (upstream stable). Distribution-specific packages will vary; consult your vendor’s security tracker for exact versions.

2. Determine Hardware Exposure

On any device that might have an Exynos SoC, check whether the ufs-exynos driver is present or loaded:
- Look for UFS entries in /sys/devices or in dmesg output.
- On a running system, lsmod | grep ufs may show the exynos UFS module if it’s in use.
If you are not sure and the device is known to have Exynos hardware, assume the driver is present and that the vulnerability applies until you can confirm otherwise.

3. Apply Vendor Patches

For most users, updating the kernel via the standard package manager is enough. Distributions like Debian, Ubuntu, and SUSE have released backported fixes. For Azure Linux, Microsoft will roll the fix into updated images; ensure you are using the latest available Azure Linux kernel package. If you maintain a custom or embedded kernel, apply the upstream patch: it modifies drivers/ufs/host/ufs-exynos.c (and related headers) to disable IOC shareability when dma-coherent is not set.

4. Validate the Fix

After rebooting into the patched kernel:
- Monitor dmesg for any UFS-related errors.
- Run a representative I/O workload to ensure stability—file copies, database operations, or any storage-intensive task can help uncover lingering issues.
- Keep an eye on system logs for a few days after the update.

5. Automate Future Detection

For enterprise environments, integrate vulnerability data feeds into your management tools. Microsoft’s CSAF/VEX documents for Azure Linux are machine-readable and can be ingested by automated scanners. However, do not rely solely on VEX attestations as a guarantee that all products are covered—maintain your own inventory of installed kernels and hardware.

The Bigger Picture: Why This CVE Matters

CVE-2025-37977 is not a flashy remote-code-execution flaw, but it highlights an increasingly important trend: the movement toward supply-chain transparency through machine-readable attestations. Microsoft’s decision to publish a VEX entry for Azure Linux is part of a broader industry effort to help customers quickly identify whether vendor-provided software includes known-vulnerable components. This is especially valuable in cloud environments, where tens of thousands of VM images may need to be assessed in minutes.

At the same time, the vulnerability underscores a timeless truth: kernel bugs that affect specific hardware can lurk for years, and when they surface, the symptoms are often vague. Exynos-powered devices are widespread in the mobile and embedded world, and a kernel update that fixes “random hangs” may go unapplied because the cause isn’t obvious. This CVE gives a name to an otherwise silent misconfiguration and demands a straightforward response: patch your kernel.

For Azure Linux users in particular, the explicit confirmation from Microsoft removes any ambiguity. For everyone else, the normal rules of vulnerability management apply: know your hardware, know your kernel, and keep both up to date.