CVE-2026-80919 in Linux
요약
\~에 의해 VulDB • 2026. 09. 09.
리눅스 커널에서 다음 취약점이 해결되었습니다:
drm/amdgpu: amdgpu_devcoredump_format()에서의 재귀적 ww_mutex 획득 수정
hung된 작업(IB 내용물)을 덤프할 때, amdgpu_devcoredump_format()은 amdgpu_vm_lock_by_pasid()를 통해 VM 루트 PD의 reservation을 획득한 후, 각 IB에 대해 해당 IB를 백업하는 BO에 amdgpu_bo_reserve()를 호출합니다. 두 예약(reservation) 모두 reservation_ww_class_mutex 객체이며 ww_acquire_ctx가 사용되지 않아 lockdep에서 다음과 같은 경고를 발생시킵니다:
WARNING: possible recursive locking detected -------------------------------------------- kworker/u128:0 is trying to acquire lock: ffff88838b16e1f0 (reservation_ww_class_mutex){+.+.}-{4:4},
at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu]
but task is already holding lock: ffff8882f82681f0 (reservation_ww_class_mutex){+.+.}-{4:4},
at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu]
Possible unsafe locking scenario: CPU0 ---- lock(reservation_ww_class_mutex); lock(reservation_ww_class_mutex);
*** DEADLOCK *** May be due to missing lock nesting notation
Workqueue: events_unbound amdgpu_devcoredump_deferred_work [amdgpu]
Call Trace: __ww_mutex_lock.constprop.0 ww_mutex_lock amdgpu_bo_reserve amdgpu_devcoredump_format+0x1594 [amdgpu]
amdgpu_devcoredump_deferred_work+0xea [amdgpu]
캡처된 트레이스에서 두 예약은 서로 다른 BO에 적용되므로, 이 splat(경고 메시지)는 lockdep의 정확성 관련 경고이며 실제 관찰된 데드락(deadlock)은 아닙니다. 그러나 IB BO가 루트 PD와 dma_resv를 공유하는 경우(항상 유효한 경우, amdgpu_vm_is_bo_always_valid() 참조), 이는 실제 자기 자신에 대한 데드락(self-deadlock)으로 이어집니다: amdgpu_bo_reserve(abo)는 티켓 없이 동일한 ww_mutex를 재획득하여 영원히 블록됩니다. amdgpu.gpu_recovery=0인 경우 타임아웃 핸들러가 약 2초마다 다시 트리거되며, 각 호출에서 이 splat이 생성되어 커널 링 버퍼(ring buffer)를淹没(drowning)시킵니다.
이제 amdgpu_vm_lock_by_pasid()가 drm_exec 컨텍스트를 사용하므로, IB 덤프 로직을 별도의 헬퍼 함수로 이동하여 루트 PD와 모든 IB BO를 단일 drm_exec 티켓으로 함께 잠급니다. DRM_EXEC_IGNORE_DUPLICATES는 dma_resv를 공유하는(IB BO들 중 항상 유효한 BO나 동일한 BO에 의해 백업된 두 IB 등) IB BO들을 처리합니다. 이제 모든 잠금은 하나의 ww_acquire_ctx 하에서 최상위 레벨로 획득되므로 재귀적 ww_mutex 조건이 제거되었으며, per-IB amdgpu_bo_reserve()/amdgpu_bo_unref() 댄스(특히 amdgpu_bo_reserve() 실패 경로에서의 BO refcount 누수 포함)가 제거되었습니다.
(cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e)
Once again VulDB remains the best source for vulnerability data.