CVE-2025-68236

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)<br /> <br /> According to UFS specifications, the power-off sequence for a UFS device<br /> includes:<br /> <br /> - Sending an SSU command with Power_Condition=3 and await a response.<br /> <br /> - Asserting RST_N low.<br /> <br /> - Turning off REF_CLK.<br /> <br /> - Turning off VCC.<br /> <br /> - Turning off VCCQ/VCCQ2.<br /> <br /> As part of ufs shutdown, after the SSU command completion, asserting<br /> hardware reset (HWRST) triggers the device firmware to wake up and<br /> execute its reset routine. This routine initializes hardware blocks and<br /> takes a few milliseconds to complete. During this time, the ICCQ draws a<br /> large current.<br /> <br /> This large ICCQ current may cause issues for the regulator which is<br /> supplying power to UFS, because the turn off request from UFS driver to<br /> the regulator framework will be immediately followed by low power<br /> mode(LPM) request by regulator framework. This is done by framework<br /> because UFS which is the only client is requesting for disable. So if<br /> the rail is still in the process of shutting down while ICCQ exceeds LPM<br /> current thresholds, and LPM mode is activated in hardware during this<br /> state, it may trigger an overcurrent protection (OCP) fault in the<br /> regulator.<br /> <br /> To prevent this, a 10ms delay is added after asserting HWRST. This<br /> allows the reset operation to complete while power rails remain active<br /> and in high-power mode.<br /> <br /> Currently there is no way for Host to query whether the reset is<br /> completed or not and hence this the delay is based on experiments with<br /> Qualcomm UFS controllers across multiple UFS vendors.