CVE-2026-93057 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Avoid possible memory reclaim deadlock in TX EQTR context
TX EQTR may run while devfreq gear scaling has quiesced the UFS tagset. In that context, functions ufshcd_tx_eqtr(), __ufshcd_tx_eqtr() and ufs_qcom_get_rx_fom() allocate memory with GFP_KERNEL. If direct reclaim is triggered, reclaim/writeback can depend on I/O to UFS device. Because the queue is quiesced, this can cause deadlock.
Use memalloc_noio_save/restore() in ufshcd_tx_eqtr() to cover all allocations in the TX EQTR call tree, including:
- params->eqtr_record in ufshcd_tx_eqtr()
- eqtr_data in __ufshcd_tx_eqtr()
- params in ufs_qcom_get_rx_fom()
This is preferred over tagging individual call sites with GFP_NOIO, as it automatically covers any future allocations added anywhere in the call tree without requiring each caller to be aware of this constraint.
[mkp: fix label as suggested by Bart]
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel contains a critical concurrency and resource management flaw within the Universal Flash Storage (UFS) host controller driver, specifically affecting the SCSI subsystem's handling of transmit event queues. This vulnerability manifests as a potential deadlock scenario during memory reclamation operations triggered in specific interrupt contexts. The core issue arises from an interaction between the device frequency scaling mechanism and the UFS tagset queue management logic. When devfreq gear scaling quiesces the UFS tagset to adjust performance parameters, it effectively pauses I/O processing for that device. However, under certain conditions, transmit event queue interrupts may still be processed while this quiescence is active. In such a state, if memory allocation fails and triggers direct reclaim, the kernel's writeback mechanism attempts to free up memory by flushing dirty pages back to storage devices. Because the UFS tagset is currently quiesced, it cannot accept or process these I/O requests required for successful reclamation. This creates a circular dependency where the system waits for I/O completion that will never occur because the queue is paused, resulting in a hard deadlock that can freeze the kernel and render the system unresponsive until a manual reset occurs.
The technical root cause lies in the use of standard GFP_KERNEL allocation flags within interrupt context functions such as ufshcd_tx_eqtr(), __ufshcd_tx_eqtr(), and ufs_qcom_get_rx_fom(). These functions are invoked during hardware event processing, which is an atomic or semi-atomic context where sleeping for memory reclamation is generally unsafe. By using GFP_KERNEL, the kernel allows these allocations to potentially sleep if free memory pages are insufficient. In normal operation, this might trigger background reclaim threads that can handle I/O freely. However, when the UFS queue is quiesced due to frequency scaling adjustments, those background threads cannot complete their work because they depend on writing data back to the very device that has stopped accepting commands. This specific sequence of events transforms a routine memory allocation into a system-wide hang condition. The vulnerability affects systems utilizing Qualcomm-based UFS controllers and other implementations where this specific interaction between power management states and interrupt handling is not properly isolated from blocking operations.
From a security and stability perspective, this flaw represents a significant availability risk. While it does not directly allow for privilege escalation or remote code execution in the traditional sense of exploiting buffer overflows, it enables local denial-of-service conditions through resource exhaustion combined with specific hardware state transitions. An attacker or even automated system load could potentially trigger high memory pressure scenarios while simultaneously inducing UFS frequency scaling events to force this deadlock condition. This aligns with CWE-835, which describes the use of a loop variable without proper bounds checking leading to infinite loops or deadlocks, and more specifically relates to resource management errors that lead to unavailability. In terms of MITRE ATT&CK mapping, this vulnerability falls under T1499: Endpoint Denial of Service, as it allows for the disruption of system availability through exploitation of kernel-level concurrency flaws. It also touches upon CWE-362 regarding concurrent execution issues where race conditions or improper synchronization lead to unexpected states like deadlocks.
The resolution implemented in this patch addresses the issue by wrapping the memory allocation calls within the TX EQTR call tree using memalloc_noio_save() and memalloc_noio_restore(). This API change effectively disables I/O submission during the critical section of memory allocation, ensuring that if direct reclaim is triggered, it will not attempt to write back data to UFS devices. Instead, the kernel will rely on other available free pages or swap space without depending on blocked storage I/O paths. This approach was chosen over individually tagging each call site with GFP_NOIO because it provides a more robust and maintainable solution. By applying the scope at the entry point of the interrupt handler's execution tree, any future allocations added to functions like ufshcd_tx_eqtr(), __ufshcd_tx_eqtr(), or ufs_qcom_get_rx_fom() are automatically protected from triggering I/O-dependent reclamation cycles. This reduces the attack surface for similar deadlocks and ensures that developers adding new features do not inadvertently reintroduce this vulnerability by forgetting to change allocation flags in isolated functions.
To mitigate the risk associated with this vulnerability, system administrators should ensure that their Linux kernels are updated to include this specific patch from the upstream kernel maintainers. For environments where immediate patching is not feasible due to stability concerns or release cycles, operational mitigations can be employed. One effective strategy involves tuning memory pressure thresholds using vm.swappiness and related sysctl parameters to encourage earlier swapping behavior before direct reclaim on block devices becomes necessary during high-load scenarios. Additionally, administrators should monitor for signs of UFS device stalls or excessive latency in storage operations, which may indicate the system is approaching a deadlock state. Disabling aggressive devfreq scaling policies that frequently quiesce I/O queues can also reduce the likelihood of triggering this specific race condition, although it may impact power efficiency and performance characteristics. Long-term mitigation requires strict adherence to kernel development best practices where interrupt context code avoids any operations that might sleep or depend on external hardware responses unless explicitly synchronized with queue states.