CVE-2026-80919 in Linuxinformação

Sumário

de VulDB • 09/09/2026

No kernel do Linux, a seguinte vulnerabilidade foi resolvida:

drm/amdgpu: corrige aquisição recursiva de ww_mutex em amdgpu_devcoredump_format

Ao despejar o conteúdo da IB (Instruction Buffer) de um trabalho travado, amdgpu_devcoredump_format() adquire a reserva do PD raiz da VM via amdgpu_vm_lock_by_pasid() e, em seguida, para cada IB, chama amdgpu_bo_reserve() no BO que suporta a IB. Ambas as reservas são objetos reservation_ww_class_mutex e nenhuma usa um ww_acquire_ctx, o que dispara o 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]

As duas reservas estão em BOs diferentes no trace capturado, portanto o splat é um aviso de correção do lockdep, não uma deadlock observada. Ele se torna uma self-deadlock real sempre que a IB BO compartilha seu dma_resv com o PD raiz (o caso always-valid, consulte amdgpu_vm_is_bo_always_valid()): amdgpu_bo_reserve(abo) re-adquire o mesmo ww_mutex sem um ticket e bloqueia para sempre. Com amdgpu.gpu_recovery=0, o manipulador de timeout é acionado novamente a cada ~2 s e cada invocação produz este splat, inundando o kernel ring buffer.

Agora que amdgpu_vm_lock_by_pasid() usa um contexto drm_exec, mova o despejo da IB para uma helper separada que bloqueia o PD raiz e todos os BOs de IB juntos em um único ticket drm_exec. DRM_EXEC_IGNORE_DUPLICATES lida com IB BOs que compartilham um dma_resv (por exemplo, BOs always-valid ou duas IBs suportadas pelo mesmo BO). Cada lock é agora uma aquisição top-level sob um ww_acquire_ctx, portanto a condição recursiva de ww_mutex foi eliminada e o dance amdgpu_bo_reserve()/amdgpu_bo_unref() por-IB -- incluindo um vazamento de refcount do BO no caminho de falha do amdgpu_bo_reserve() -- foi removido.

(cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e)

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Responsável

Linux

Reservar

26/08/2026

Divulgação

09/09/2026

Moderação

aceite

Entrada

VDB-401818

CPE

pronto

EPSS

0.00000

KEV

não

Atividades

baixo

Fontes

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!