Description
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]
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service due to a kernel deadlock
Action: Apply Patch
AI Analysis

Impact

The vulnerability resides in the Linux kernel's UFS core driver. When the transmitter EQTR routine executes while devfreq gear scaling has quiesced the UFS tagset, several allocations are performed with GFP_KERNEL. If a direct memory reclaim is triggered under these conditions, the reclaim or write‑back paths can stall on I/O to a device that is itself quiesced, leading to a deadlock that stalls the scheduler and effectively denies service.

Affected Systems

Any Linux installation that incorporates the UFS core driver without the recent patch is potentially affected. This includes all mainstream distributions distributing affected kernel versions, though exact vulnerable versions have not been enumerated. The issue does not involve specific component versions beyond the kernel itself.

Risk and Exploitability

The EPSS score is below 1 %, indicating that no public exploits are currently known. The mechanism requires the TX EQTR path to run while the UFS queue is quiesced, a state that is usually achieved by local power‑management or intensive I/O workloads. An attacker would therefore need local or root access to trigger the conditions, so the likelihood of exploitation is low but not zero. The vulnerability is not listed in the CISA KEV catalog.

Generated by OpenCVE AI on September 19, 2026 at 09:17 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that contains the memalloc_noio_save/restore patch for the UFS core TX EQTR path.
  • If a kernel upgrade is not possible, avoid triggering TX EQTR while the UFS queue is quiesced, for example by disabling UFS power‑management features or ensuring the device remains active during critical operations.
  • Track system logs for evidence of memory reclaim stalls or UFS I/O timeouts, and apply vendor‑issued updates as soon as they are published.
  • In environments where disabling UFS is viable, replace UFS storage with an alternative block device to eliminate the risk entirely.

Generated by OpenCVE AI on September 19, 2026 at 09:17 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 19 Sep 2026 09:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-667

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Description 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]
Title scsi: ufs: core: Avoid possible memory reclaim deadlock in TX EQTR context
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-17T16:10:45.108Z

Reserved: 2026-09-17T15:57:05.659Z

Link: CVE-2026-93057

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:17:59.323

Modified: 2026-09-17T17:17:59.323

Link: CVE-2026-93057

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-19T13:15:16Z

Weaknesses