Bug 2536231 (CVE-2026-93057) - CVE-2026-93057 kernel: scsi: ufs: core: Avoid possible memory reclaim deadlock in TX EQTR context
Summary: CVE-2026-93057 kernel: scsi: ufs: core: Avoid possible memory reclaim deadloc...
Keywords:
Status: NEW
Alias: CVE-2026-93057
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-09-17 17:01 UTC by OSIDB Bzimport
Modified: 2026-10-20 11:28 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-09-17 17:01:17 UTC
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]


Note You need to log in before you can comment on or make changes to this bug.