2.8 KiB
CVE-2024-56552
Description
In the Linux kernel, the following vulnerability has been resolved:drm/xe/guc_submit: fix race around suspend_pendingCurrently in some testcases we can trigger:xe 0000:03:00.0: [drm] Assertion exec_queue_destroyed(q) failed!....WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe]xe 0000:03:00.0: [drm] ERROR GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57Looking at a snippet of corresponding ftrace for this GuC id we can see:162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0It looks like we try to suspend the queue (opcode=3), settingsuspend_pending and triggering a disable_scheduling. The user thencloses the queue. However the close will also forcefully signal thesuspend fence after killing the queue, later when the G2H response fordisable_scheduling comes back we have now cleared suspend_pending whensignalling the suspend fence, so the disable_scheduling now incorrectlytries to also deregister the queue. This leads to warnings since the queuehas yet to even be marked for destruction. We also seem to triggererrors later with trying to double unregister the same queue.To fix this tweak the ordering when handling the response to ensure wedon't race with a disable_scheduling that didn't actually intend toperform an unregister. The destruction path should now also correctlywait for any pending_disable before marking as destroyed.(cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)
POC
Reference
No PoCs from references.