{
  "cveId": "CVE-2026-80919",
  "url": "https://patchblox.com/security/cve/CVE-2026-80919",
  "summary": "CVE-2026-80919 is fixed in linux on 1 platform by DEBIAN-CVE-2026-80919 (version 7.1.12-1), released September 10, 2026. It is not reported as exploited. Patch Radar priority: Routine.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix recursive ww_mutex acquire in am...",
  "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\u0027s 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){\u002B.\u002B.}-{4:4},     at: amdgpu_devcoredump_format\u002B0x1594/0x23f0 [amdgpu]    but task is already holding lock:   ffff8882f82681f0 (reservation_ww_class_mutex){\u002B.\u002B.}-{4:4},     at: amdgpu_devcoredump_format\u002B0x1594/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\u002B0x1594 [amdgpu]    amdgpu_devcoredump_deferred_work\u002B0xea [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)",
  "published": "2026-09-09T17:17:47Z",
  "severity": "",
  "epss": 0.00198,
  "epssPercentile": 0.09579,
  "priority": "Routine",
  "priorityTier": 4,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "7.1.12-1",
      "fix": "DEBIAN-CVE-2026-80919",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2026-80919",
      "released": "2026-09-10T12:12:19Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-08T06:59:42Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}