PT-2026-89089 · Linux · Linux
CVE-2026-80919
·
Published
2026-09-09
·
Updated
2026-09-09
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix recursive ww mutex acquire in amdgpu devcoredump format
When dumping IB contents from a hung job, amdgpu devcoredump format()
acquired the VM root PD's reservation via amdgpu vm lock by pasid() and
then, for each IB, called amdgpu bo reserve() on the BO backing the IB.
Both reservations are reservation ww class mutex objects and neither
used a ww acquire ctx, which trips 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]
The two reservations are on different BOs in the captured trace, so the
splat is a lockdep-correctness warning, not an observed deadlock. It
becomes a real self-deadlock whenever the IB BO shares its dma resv with
the root PD (the always-valid case, see amdgpu vm is bo always valid()):
amdgpu bo reserve(abo) re-acquires the same ww mutex without a ticket
and blocks forever. With amdgpu.gpu recovery=0 the timeout handler
refires every ~2 s and each invocation produces this splat, drowning the
kernel ring buffer.
Now that amdgpu vm lock by pasid() takes a drm exec context, move the IB
dumping into a separate helper that locks the root PD and every IB BO
together in a single drm exec ticket. DRM EXEC IGNORE DUPLICATES handles
IB BOs that share a dma resv (e.g. always-valid BOs, or two IBs backed
by the same BO). Every lock is now a top-level acquire under one
ww acquire ctx, so the recursive ww mutex condition is gone, and the
per-IB amdgpu bo reserve()/amdgpu bo unref() dance -- including a BO
refcount leak on the amdgpu bo reserve() failure path -- is removed.
(cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e)
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux