CVE-2023-52625

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Refactor DMCUB enter/exit idle interface<br /> <br /> [Why]<br /> We can hang in place trying to send commands when the DMCUB isn&amp;#39;t<br /> powered on.<br /> <br /> [How]<br /> We need to exit out of the idle state prior to sending a command,<br /> but the process that performs the exit also invokes a command itself.<br /> <br /> Fixing this issue involves the following:<br /> <br /> 1. Using a software state to track whether or not we need to start<br /> the process to exit idle or notify idle.<br /> <br /> It&amp;#39;s possible for the hardware to have exited an idle state without<br /> driver knowledge, but entering one is always restricted to a driver<br /> allow - which makes the SW state vs HW state mismatch issue purely one<br /> of optimization, which should seldomly be hit, if at all.<br /> <br /> 2. Refactor any instances of exit/notify idle to use a single wrapper<br /> that maintains this SW state.<br /> <br /> This works simialr to dc_allow_idle_optimizations, but works at the<br /> DMCUB level and makes sure the state is marked prior to any notify/exit<br /> idle so we don&amp;#39;t enter an infinite loop.<br /> <br /> 3. Make sure we exit out of idle prior to sending any commands or<br /> waiting for DMCUB idle.<br /> <br /> This patch takes care of 1/2. A future patch will take care of wrapping<br /> DMCUB command submission with calls to this new interface.