scsi: ufs: core: Avoid possible memory reclaim deadlock in TX EQTR context
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 7.2.6
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
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, 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]
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From 03e5d38e2f985d8d0b0a60508c0b422f664808e3 · fixed in a28a7d9b3bb116da788ae492c90465ec1a7fa6e8; From 03e5d38e2f985d8d0b0a60508c0b422f664808e3 · fixed in 760fc6f0e25a72832c2fcf37ecf5f1b770ec8374
- Linux Linux
7.1
- KernelLinux
From 7.1.0 · fixed in 7.2.6