CVE-2026-80919

CVE-2026-80919

published September 9, 2026

CVSS
—
EPSS
0%
Percentile
9.0
In the wild
Unconfirmed
What it is

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)

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00198 · 9.0th percentile
Published
2026-09-09T21:17Z
References (2)
EPSS history
Timeline
  • 11 SEP 03:19Z
    EPSS moved — → 0%
    epss
  • 09 SEP 16:13Z
    drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format
    cvelistv5