---
id: CVE-2026-93057
title: |-
  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
summary: |-
  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, fun…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 03e5d38e2f985d8d0b0a60508c0b422f664808e3 <
    a28a7d9b3bb116da788ae492c90465ec1a7fa6e8
  - >-
    Linux >= 03e5d38e2f985d8d0b0a60508c0b422f664808e3 <
    760fc6f0e25a72832c2fcf37ecf5f1b770ec8374
  - Linux 7.1
published: '2026-09-17'
updated: '2026-09-17'
sourceUpdated: '2026-09-17T17:17:59.323'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-93057'
references:
  - url: 'https://git.kernel.org/stable/c/760fc6f0e25a72832c2fcf37ecf5f1b770ec8374'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/a28a7d9b3bb116da788ae492c90465ec1a7fa6e8'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
ingestedAt: '2026-09-17T16:21:47.769Z'
epss: 0.00155
epssPercentile: 0.05071
---

## Overview

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]

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.