🇰🇷 한글 설명
Linux 커널의 DRM XE 드라이버에서 suspend_pending 상태와 관련된 레이스 컨디션 취약점이 발견되었습니다. 큐를 일시 중단하는 과정에서 사용자가 큐를 닫을 경우, 비정상적인 상태 변화로 인해 커널 경고 및 중복 등록 해제 오류가 발생할 수 있습니다.
💡 쉬운 설명
그래픽 카드를 제어하는 소프트웨어에서 작업 순서가 꼬여 발생하는 오류입니다. 특정 상황에서 시스템이 명령을 잘못 처리하여 그래픽 드라이버가 충돌하거나 불안정해질 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/guc_submit: fix race around suspend_pending
Currently 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=57
Looking 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=3
162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3
162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0
162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0
162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0
162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0
162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0
It looks like we try to suspend the queue (opcode=3), setting
suspend_pending and triggering a disable_scheduling. The user then
closes the queue. However the close will also forcefully signal the
suspend fence after killing the queue, later when the G2H response for
disable_scheduling comes back we have now cleared suspend_pending when
signalling the suspend fence, so the disable_scheduling now incorrectly
tries to also deregister the queue. This leads to warnings since the queue
has yet to even be marked for destruction. We also seem to trigger
errors later with trying to double unregister the same queue.
To fix this tweak the ordering when handling the response to ensure we
don't race with a disable_scheduling that didn't actually intend to
perform an unregister. The destruction path should now also correctly
wait for any pending_disable before marking as destroyed.
(cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)
📍 영향받는 시스템
Linux kernel (DRM XE driver component)
⚔️ 공격 벡터
로컬 사용자가 특정 그래픽 작업 큐를 생성하고 일시 중단과 동시에 닫는 정교한 타이밍 공격
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전(commit f161809b362f027b6d72bd998e47f8f0bad60a2e 이상)으로 업데이트하십시오.
🔧 검증 코드
현재 커널 버전과 해당 취약점이 수정된 소스 코드의 수정 사항이 반영되어 있는지 확인합니다.
uname -r && grep -r "xe_guc_sched_done_handler" /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/xe/ 2>/dev/null