CVE-2024-53153

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()<br /> <br /> Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF<br /> deinit notify function pci_epc_deinit_notify() are called during the<br /> execution of qcom_pcie_perst_assert() i.e., when the host has asserted<br /> PERST#. But quickly after this step, refclk will also be disabled by the<br /> host.<br /> <br /> All of the Qcom endpoint SoCs supported as of now depend on the refclk from<br /> the host for keeping the controller operational. Due to this limitation,<br /> any access to the hardware registers in the absence of refclk will result<br /> in a whole endpoint crash. Unfortunately, most of the controller cleanups<br /> require accessing the hardware registers (like eDMA cleanup performed in<br /> dw_pcie_ep_cleanup(), powering down MHI EPF etc...). So these cleanup<br /> functions are currently causing the crash in the endpoint SoC once host<br /> asserts PERST#.<br /> <br /> One way to address this issue is by generating the refclk in the endpoint<br /> itself and not depending on the host. But that is not always possible as<br /> some of the endpoint designs do require the endpoint to consume refclk from<br /> the host (as I was told by the Qcom engineers).<br /> <br /> Thus, fix this crash by moving the controller cleanups to the start of<br /> the qcom_pcie_perst_deassert() function. qcom_pcie_perst_deassert() is<br /> called whenever the host has deasserted PERST# and it is guaranteed that<br /> the refclk would be active at this point. So at the start of this function<br /> (after enabling resources), the controller cleanup can be performed. Once<br /> finished, rest of the code execution for PERST# deassert can continue as<br /> usual.