https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 22:15:46 +0000 https://db.gcve.eu/vuln/cve-2026-93057 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>scsi: ufs: core: Avoid possible memory reclaim deadlock in TX EQTR context</p> <p>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.</p> <p>Use memalloc_noio_save/restore() in ufshcd_tx_eqtr() to cover all allocations in the TX EQTR call tree, including:</p> <p>- params-&gt;eqtr_record in ufshcd_tx_eqtr()</p> <p>- eqtr_data in __ufshcd_tx_eqtr()</p> <p>- params in ufs_qcom_get_rx_fom()</p> <p>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.</p> <p>[mkp: fix label as suggested by Bart]</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>scsi: ufs: core: Avoid possible memory reclaim deadlock in TX EQTR context</p> <p>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.</p> <p>Use memalloc_noio_save/restore() in ufshcd_tx_eqtr() to cover all allocations in the TX EQTR call tree, including:</p> <p>- params-&gt;eqtr_record in ufshcd_tx_eqtr()</p> <p>- eqtr_data in __ufshcd_tx_eqtr()</p> <p>- params in ufs_qcom_get_rx_fom()</p> <p>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.</p> <p>[mkp: fix label as suggested by Bart]</p> https://db.gcve.eu/vuln/cve-2026-93057