🇰🇷 한글 설명
리눅스 커널의 drm/sched 구성 요소에서 drm_sched_entity_kill_jobs_cb 함수 호출 시 데드락(교착 상태)이 발생할 수 있는 취약점이 발견되었습니다. 이는 인터럽트 컨텍스트와 일반 프로세스 컨텍스트 간의 잠금 순서 불일치로 인해 발생하며, 시스템이 멈출 수 있습니다.
💡 쉬운 설명
컴퓨터의 그래픽 처리 관련 작업 중 두 가지 작업이 서로의 자원을 기다리며 무한히 대기하는 상태가 발생할 수 있습니다. 이로 인해 시스템이 응답하지 않거나 멈추는 현상이 나타날 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb
The Mesa issue referenced below pointed out a possible deadlock:
[ 1231.611031] Possible interrupt unsafe locking scenario:
[ 1231.611033] CPU0 CPU1
[ 1231.611034] ---- ----
[ 1231.611035] lock(&xa->xa_lock#17);
[ 1231.611038] local_irq_disable();
[ 1231.611039] lock(&fence->lock);
[ 1231.611041] lock(&xa->xa_lock#17);
[ 1231.611044] <Interrupt>
[ 1231.611045] lock(&fence->lock);
[ 1231.611047]
*** DEADLOCK ***
In this example, CPU0 would be any function accessing job->dependencies
through the xa_* functions that don't disable interrupts (eg:
drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).
CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling
callback so in an interrupt context. It will deadlock when trying to
grab the xa_lock which is already held by CPU0.
Replacing all xa_* usage by their xa_*_irq counterparts would fix
this issue, but Christian pointed out another issue: dma_fence_signal
takes fence.lock and so does dma_fence_add_callback.
dma_fence_signal() // locks f1.lock
-> drm_sched_entity_kill_jobs_cb()
-> foreach dependencies
-> dma_fence_add_callback() // locks f2.lock
This will deadlock if f1 and f2 share the same spinlock.
To fix both issues, the code iterating on dependencies and re-arming them
is moved out to drm_sched_entity_kill_jobs_work().
[phasta: commit message nits]
📍 영향받는 시스템
Linux Kernel (drm/sched 모듈을 사용하는 시스템)
⚔️ 공격 벡터
특정 그래픽 작업(fence signaling)을 유도하여 커널의 잠금 충돌을 일으키는 방식
🛡️ 대응 방법
리눅스 커널을 최신 보안 패치가 적용된 버전으로 업데이트하십시오.
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 수정된 패치 버전 이후인지 확인하십시오.