A newly disclosed Linux kernel vulnerability that can deadlock systems using Universal Flash Storage (UFS) has drawn attention from Microsoft, which confirmed its Azure Linux distribution may be affected. The fix—a single-line-ordering change in the SCSI UFS driver—has already been backported to stable kernel trees, and Azure Linux maintainers are expected to include it in their rolling updates.

The flaw, tracked as CVE-2025-38119, sits deep in the UFS error-handling path. When a storage device encounters a fault and the kernel tries to recover, a driver flag and a power-management call collide, creating a deadlock that halts I/O indefinitely without a reboot. For anyone running UFS hardware—primarily mobile devices, embedded appliances, and some cloud virtual machines—this is a plain availability risk requiring prompt patching.

What actually happens inside the kernel

The bug lives in the ufshcd driver’s error-preparation function. When the driver starts recovery, it sets a flag called UFSHCD_EH_IN_PROGRESS and then attempts to resume runtime power management. But that resume itself requires issuing SCSI commands through ufshcd_queuecommand—which sees the EH_IN_PROGRESS flag and immediately returns HOST_BUSY, blocking the resume. The driver ends up waiting forever for a resume that can never complete because the flag it just set is preventing it.

According to the kernel advisory, the symptom is a set of worker threads stuck in kernel wait primitives, with backtraces showing ufshcd_wl_runtime_resume waiting on a blk_execute_rq that never finishes. The fix swaps two lines: call the resume first, then set the flag only after success. If the resume fails, the error handler proceeds normally instead of locking up.

The change is intentionally tiny—just a reorder in drivers/ufs/core/ufshcd.c—making it a safe cherry-pick for distribution maintainers. Upstream merged it into Linus Torvalds’ tree, and stable branches from 5.4 onward have received backports.

What this means for you

For Azure Linux administrators: Microsoft’s Security Response Center indicates Azure Linux is the only Microsoft product that potentially includes the vulnerable component. The distro’s rolling release model means kernels are frequently refreshed; if you run Azure Linux, check your installed kernel version and apply the latest updates immediately. Microsoft’s advisory explicitly says the team is “committed to transparency” and will update the CVE if other products are affected, but for now the scope is contained.

For embedded and mobile device operators: This is your domain. UFS is the storage interface inside many Android phones, industrial tablets, and IoT gateways. Kernel logs showing a stuck ufshcd error handler or repeated runtime-PM resume failures are the telltale sign. If you use a vendor-supplied BSP (board support package), contact the OEM for a patched image. Many vendors like Ubuntu and Oracle have already published fixed packages.

For traditional Windows and WSL users: Windows itself does not ship the Linux UFS driver, so the OS is not vulnerable. Even WSL2, which runs a Linux kernel, does not expose UFS hardware to the virtual machine—WSL2 uses a virtual ext4 volume on a VHDX file, not physical storage interfaces. However, if you maintain custom WSL2 kernels for special hardware, verify your config does not enable UFS support unnecessarily.

For general server admins: Most x86 server-class machines lack UFS controllers entirely. If your fleet is all standard servers, this CVE is low priority. But scan your configuration management databases for any appliance or edge server that may run an AArch64 or embedded kernel—those are the hidden gotchas.

How we got here

Universal Flash Storage became the successor to eMMC in mobile devices, offering faster speeds and lower power. Linux kernel support was added years ago and has matured, but like any complex driver, edge cases in error recovery can linger. The ufshcd driver handles the SCSI command translation for UFS host controllers, and its error handler must coordinate with runtime power management to avoid leaving the device in a bad state.

The particular deadlock pattern—setting a state flag that later blocks an operation required to proceed—is a well-known class of kernel bug. Similar issues have appeared in USB and PCIe drivers. The fix here follows the same surgical style favored by kernel maintainers: change the order, don’t redesign the whole function.

The vulnerability was assigned CVE-2025-38119 and scored 5.5 (CVSS v3.1), reflecting a local attack vector and availability-only impact. The Linux kernel CVE team published the announcement, and distributors quickly mapped the fix into their update channels. Ubuntu’s USN and Oracle Linux’s errata pages list patched kernel versions. Microsoft’s advisory, published on the Security Response Center portal, notes Azure Linux’s potential exposure and references the upstream fix.

What to do now

  1. Inventory your Linux systems. Run lsmod | grep ufshcd or check kernel config (zgrep UFS /proc/config.gz) to see if the driver is loaded. For embedded devices, consult your device documentation.
  2. Check logs for symptoms. Search dmesg or journalctl -k for messages containing ufshcd, UFSHCD_EH_IN_PROGRESS, or runtime resume failures. A matching backtrace with io_schedule_timeout and blk_execute_rq near ufshcd_set_dev_pwr_mode is a smoking gun.
  3. Apply vendor updates. For Azure Linux, run apt-get update && apt-get upgrade (or tdnf depending on version) to pull the latest kernel. For other distributions, refer to the vendor advisory: Ubuntu users need kernel package linux-image-X.X.X-XX-generic updated, Oracle Linux users should enable the UEKR7 repo for the fix.
  4. If you can’t patch immediately, mitigate by blacklisting the ufshcd module (blacklist ufshcd in /etc/modprobe.d/) on systems where UFS is not required. Note this will remove access to UFS storage entirely, so verify impact first.
  5. Test recovery scenarios. After updating, simulate a storage error in a lab environment (e.g., using scsi_debug with fault injection) to confirm that error recovery no longer hangs.

The bigger picture

This CVE underscores a recurring truth: availability bugs in error-handling code can be just as disruptive as remote code execution flaws. A hang in a kernel thread can stall backups, prevent clean shutdowns, and force hard reboots. For appliances and edge devices that run unattended, an unrecoverable hang can mean hours of downtime before someone physically resets the box.

The fix’s small size is a testament to how effective code review and thorough testing can be—the community caught a subtle ordering problem and fixed it with minimal churn. For IT operators, the lesson is to track vulnerability announcements not just for “remote” attack vectors, but also for local availability issues that could bite during routine maintenance or unexpected hardware faults.

Microsoft’s engagement here, though limited to Azure Linux, shows the company’s increasing openness around open-source security. By publishing its CSAF/VEX data, it allows customers to programmatically determine exposure. For any organization running Azure Linux in production, this is a straightforward update—apply it, reboot, and move on.