CVE-2024-53152

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_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 pex_ep_event_pex_rst_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 tegra194 endpoint SoCs supported as of now depend on the refclk<br /> from the host for keeping the controller operational. Due to this<br /> limitation, any access to the hardware registers in the absence of refclk<br /> will result in a whole endpoint crash. Unfortunately, most of the<br /> controller cleanups require accessing the hardware registers (like eDMA<br /> cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup<br /> functions can cause the crash in the endpoint SoC once host 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.<br /> <br /> Thus, fix this crash by moving the controller cleanups to the start of<br /> the pex_ep_event_pex_rst_deassert() function. This function is called<br /> whenever the host has deasserted PERST# and it is guaranteed that the<br /> 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.