In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
drm\/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format<\/p>\n
When dumping IB contents from a hung job, amdgpu_devcoredump_format()
\nacquired the VM root PD’s reservation via amdgpu_vm_lock_by_pasid() and
\nthen, for each IB, called amdgpu_bo_reserve() on the BO backing the IB.
\nBoth reservations are reservation_ww_class_mutex objects and neither
\nused a ww_acquire_ctx, which trips lockdep:<\/p>\n
WARNING: possible recursive locking detected
\n ——————————————–
\n kworker\/u128:0 is trying to acquire lock:
\n ffff88838b16e1f0 (reservation_ww_class_mutex){+.+.}-{4:4},
\n at: amdgpu_devcoredump_format+0x1594\/0x23f0 [amdgpu]<\/p>\n
but task is already holding lock:
\n ffff8882f82681f0 (reservation_ww_class_mutex){+.+.}-{4:4},
\n at: amdgpu_devcoredump_format+0x1594\/0x23f0 [amdgpu]<\/p>\n
Possible unsafe locking scenario:
\n CPU0
\n —-
\n lock(reservation_ww_class_mutex);
\n lock(reservation_ww_class_mutex);<\/p>\n
*** DEADLOCK ***
\n May be due to missing lock nesting notation<\/p>\n
Workqueue: events_unbound amdgpu_devcoredump_deferred_work [amdgpu]
\n Call Trace:
\n __ww_mutex_lock.constprop.0
\n ww_mutex_lock
\n amdgpu_bo_reserve
\n amdgpu_devcoredump_format+0x1594 [amdgpu]
\n amdgpu_devcoredump_deferred_work+0xea [amdgpu]<\/p>\n
The two reservations are on different BOs in the captured trace, so the
\nsplat is a lockdep-correctness warning, not an observed deadlock. It
\nbecomes a real self-deadlock whenever the IB BO shares its dma_resv with
\nthe root PD (the always-valid case, see amdgpu_vm_is_bo_always_valid()):
\namdgpu_bo_reserve(abo) re-acquires the same ww_mutex without a ticket
\nand blocks forever. With amdgpu.gpu_recovery=0 the timeout handler
\nrefires every ~2 s and each invocation produces this splat, drowning the
\nkernel ring buffer.<\/p>\n
Now that amdgpu_vm_lock_by_pasid() takes a drm_exec context, move the IB
\ndumping into a separate helper that locks the root PD and every IB BO
\ntogether in a single drm_exec ticket. DRM_EXEC_IGNORE_DUPLICATES handles
\nIB BOs that share a dma_resv (e.g. always-valid BOs, or two IBs backed
\nby the same BO). Every lock is now a top-level acquire under one
\nww_acquire_ctx, so the recursive ww_mutex condition is gone, and the
\nper-IB amdgpu_bo_reserve()\/amdgpu_bo_unref() dance — including a BO
\nrefcount leak on the amdgpu_bo_reserve() failure path — is removed.<\/p>\n
(cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e)<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
drm\/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format<\/p>\n
When dumping IB contents from a hung job, amdgpu_devcoredu<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-20402","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/20402","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=20402"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=20402"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=20402"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}