Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1336 CNY

100%

CVE-2026-80919— drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format

Quick assessment

Affected
Linux Linux
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.

在 Linux 内核中,已修复以下漏洞: drm/amdgpu:修复 amdgpu_devcoredump_format 中递归获取 ww_mutex 的问题 当从挂起的任务中转储 IB 内容时, 会通过 获取 VM 根页目录(PD)的保留锁(reservation),随后对每个 IB 的后备内存对象(BO)调用 。这两个保留锁都是 对象,且两者在获取时均未使用 (wait-wake 上下文),从而触发了 lockdep 告警: 在捕获到的调用栈中,这两个保留锁分别位于不同的 BO 上,因此该告警属于 lockde

AI Predicted 5.5 Difficulty: Hard

Possible ATT&CK Techniques 2 AI

T1184 T1531 · Account Access Removal

Affected Version Matrix 6

VendorProduct Version RangeStatus
Linux Linux 7b15fc2d1f1a00fb99f0146e404ff2600999ec74< 4e9b4dee0777ec9c835a4746e2d30382dd9d1044 affected
7b15fc2d1f1a00fb99f0146e404ff2600999ec74< 7152b248dc3c8d5fa8629e99ed5655dd41b51562 affected
7.1 affected
< 7.1 unaffected
7.1.11≤ 7.1.* unaffected
7.2≤ * unaffected
Get alerts for future matching vulnerabilities Log in to subscribe

I. Basic Information for CVE-2026-80919

Vulnerability Information

Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format
Source: CVE Program / CVE List V5
Vulnerability Description
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)
Source: CVE Program / CVE List V5
CVSS Information
N/A
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5

Affected Products

Vendor Product Affected Versions CPE Subscribe
Linux Linux 7b15fc2d1f1a00fb99f0146e404ff2600999ec74 ~ 4e9b4dee0777ec9c835a4746e2d30382dd9d1044 -
Linux Linux 7.1 -

II. Public POCs for CVE-2026-80919

# POC Description Source Link Shenlong Link
AI-Generated POC Premium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2026-80919

登录查看更多情报信息。

Patches & Fixes for CVE-2026-80919 (2)

Same Patch Batch · Linux · 2026-09-09 · 12 CVEs total

CVE-2026-80925 vlan: fix skb_under_panic and races when toggling HW VLAN offload
CVE-2026-80924 crypto: krb5 - use kfree_sensitive() for derived key buffers
CVE-2026-80923 xhci: dbgtty: Fix unregister on tty_register_driver() failure
CVE-2026-80922 crypto: qcom-rng - Allow zero as a random number
CVE-2026-80921 KVM: s390: vsie: zero stale crypto bits
CVE-2026-80920 io_uring: defer eventfd signaling when queued from a wakeup handler
CVE-2026-80918 HID: core: fix number/pointer type confusion on long items
CVE-2026-80917 PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems
CVE-2026-80916 kcov: fix data corruption and race conditions on PREEMPT_RT
CVE-2026-80915 drm/xe: Fix DPT allocation paths.
CVE-2026-80914 Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready

IV. Related Vulnerabilities

V. Comments for CVE-2026-80919

No comments yet


Leave a comment