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

CVE-2026-80919

Affected Products

Linux