CVE-2026-80919 in Linux
Tóm tắt
Bởi VulDB • 09/09/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
drm/amdgpu: sửa lỗi acquire ww_mutex đệ quy trong amdgpu_devcoredump_format
Khi dump nội dung IB từ một job bị treo (hung), hàm `amdgpu_devcoredump_format()` thực hiện việc reserve root PD của VM thông qua `amdgpu_vm_lock_by_pasid()`, và sau đó, với mỗi IB, gọi `amdgpu_bo_reserve()` trên BO hỗ trợ cho IB. Cả hai lệnh reserve đều là các đối tượng mutex reservation_ww_class_mutex và không sử dụng ww_acquire_ctx, điều này kích hoạt cảnh báo từ 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]
Hai lệnh reserve này nằm trên các BO khác nhau trong bản ghi (trace) được capture, do đó thông báo splat là một cảnh báo về tính đúng đắn của lockdep chứ không phải là một deadlock thực tế đã quan sát được. Tuy nhiên, nó trở thành một self-deadlock khi IB BO chia sẻ dma_resv với root PD (trường hợp luôn hợp lệ, xem amdgpu_vm_is_bo_always_valid()): `amdgpu_bo_reserve(abo)` sẽ acquire lại cùng một ww_mutex mà không có ticket và bị block mãi mãi. Với tham số `amdgpu.gpu_recovery=0`, bộ xử lý timeout sẽ được kích hoạt lặp lại mỗi ~2 giây và mỗi lần gọi đều tạo ra thông báo splat này, làm ngập kernel ring buffer.
Bây giờ khi `amdgpu_vm_lock_by_pasid()` nhận một ngữ cảnh drm_exec, việc dump IB đã được chuyển vào một hàm trợ giúp riêng biệt để lock root PD và mọi BO của IB cùng nhau trong một ticket drm_exec duy nhất. DRM_EXEC_IGNORE_DUPLICATES xử lý các IB BO chia sẻ dma_resv (ví dụ: các BO luôn hợp lệ, hoặc hai IBs được hỗ trợ bởi cùng một BO). Mọi lệnh acquire giờ đây đều là top-level dưới một ww_acquire_ctx duy nhất, do đó điều kiện recursive ww_mutex đã biến mất, và chuỗi thao tác per-IB `amdgpu_bo_reserve()`/`amdgpu_bo_unref()` -- bao gồm cả việc rò rỉ refcount của BO trên đường dẫn thất bại của `amdgpu_bo_reserve()` -- đã được loại bỏ.
(cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e)
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.