Cloudanix VulnDB

CVE-2026-93057

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A storage driver bug in Linux can make some computers freeze when the system tries to manage power or performance on certain flash drives.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

In the Linux kernel UFS driver, TX EQTR context runs while the tagset is quiesced by devfreq scaling; GFP_KERNEL allocations in ufshcd_tx_eqtr, __ufshcd_tx_eqtr and ufs_qcom_get_rx_fom can trigger direct reclaim that depends on blocked UFS I/O, resulting in deadlock.

Why it matters to the business

Systems using UFS storage may experience sudden hangs or require reboots during normal power or performance scaling events, disrupting workloads until the kernel is updated.

How an attack unfolds

An attacker with local code execution or the ability to influence devfreq scaling and memory pressure can trigger the quiesced state and subsequent reclaim, causing the deadlock; no remote unauthenticated path is known.

How to fix it

Update the Linux kernel to a version containing the memalloc_noio_save/restore wrapper in ufshcd_tx_eqtr; rebuild and reboot affected hosts.

How to confirm the fix worked

Confirm the patch is present by inspecting the ufshcd_tx_eqtr function for the memalloc_noio_save/restore calls; monitor for absence of UFS-related deadlocks under devfreq scaling and memory pressure.

Typical attack path

  1. Obtain local execution or trigger memory pressure on a UFS-based system
  2. Force devfreq gear scaling to quiesce the UFS tagset
  3. Induce GFP_KERNEL allocation inside the TX EQTR call tree
  4. Trigger direct reclaim that waits on the blocked UFS queue

How to detect it

Review kernel logs for hung-task or deadlock traces involving ufshcd_tx_eqtr or UFS tagset quiesce; correlate with devfreq scaling events and memory-reclaim activity.

What your security team should do

  • Prioritize kernel updates on all UFS-equipped servers and embedded devices
  • Test the updated kernel under synthetic devfreq and memory-reclaim workloads before broad deployment
  • Add kernel oops and hung-task detectors to existing monitoring for early deadlock signals

The record

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]

Affected packages

Ecosystem Package Introduced Fixed