CVE-2023-53351

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sched: Check scheduler work queue before calling timeout handling<br /> <br /> During an IGT GPU reset test we see again oops despite of<br /> commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling<br /> timeout handling).<br /> <br /> It uses ready condition whether to call drm_sched_fault which unwind<br /> the TDR leads to GPU reset.<br /> However it looks the ready condition is overloaded with other meanings,<br /> for example, for the following stack is related GPU reset :<br /> <br /> 0 gfx_v9_0_cp_gfx_start<br /> 1 gfx_v9_0_cp_gfx_resume<br /> 2 gfx_v9_0_cp_resume<br /> 3 gfx_v9_0_hw_init<br /> 4 gfx_v9_0_resume<br /> 5 amdgpu_device_ip_resume_phase2<br /> <br /> does the following:<br /> /* start the ring */<br /> gfx_v9_0_cp_gfx_start(adev);<br /> ring-&gt;sched.ready = true;<br /> <br /> The same approach is for other ASICs as well :<br /> gfx_v8_0_cp_gfx_resume<br /> gfx_v10_0_kiq_resume, etc...<br /> <br /> As a result, our GPU reset test causes GPU fault which calls unconditionally gfx_v9_0_fault<br /> and then drm_sched_fault. However now it depends on whether the interrupt service routine<br /> drm_sched_fault is executed after gfx_v9_0_cp_gfx_start is completed which sets the ready<br /> field of the scheduler to true even for uninitialized schedulers and causes oops vs<br /> no fault or when ISR drm_sched_fault is completed prior gfx_v9_0_cp_gfx_start and<br /> NULL pointer dereference does not occur.<br /> <br /> Use the field timeout_wq to prevent oops for uninitialized schedulers.<br /> The field could be initialized by the work queue of resetting the domain.<br /> <br /> v1: Corrections to commit message (Luben)