CVE-2026-80919 in LinuxИнформация

Сводка

по VulDB • 09.09.2026

В ядре Linux была устранена следующая уязвимость:

drm/amdgpu: исправлено рекурсивное получение ww_mutex в amdgpu_devcoredump_format

При выводе содержимого IB (Instruction Buffer) из зависшего задания функция amdgpu_devcoredump_format() получала блокировку резервирования корневого PD виртуальной памяти через amdgpu_vm_lock_by_pasid(), а затем для каждого IB вызывала amdgpu_bo_reserve() для BO, обеспечивающего хранение данных IB. Обе блокировки являются объектами reservation_ww_class_mutex, и ни одна из них не использовала ww_acquire_ctx, что вызывает срабатывание 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]

Эти две блокировки относятся к разным BO в захваченном трассировке, поэтому данное сообщение lockdep является предупреждением о корректности работы с блокировками, а не зафиксированным взаимоблокированием (deadlock). Однако оно превращается в реальное само-взаимоблокирование всякий раз, когда IB BO разделяет свой dma_resv с корневым PD (случай «always-valid», см. amdgpu_vm_is_bo_always_valid()): вызов amdgpu_bo_reserve(abo) повторно получает ту же самую ww_mutex без ticket и блокируется навсегда. При параметре amdgpu.gpu_recovery=0 обработчик тайм-аута срабатывает каждые ~2 секунды, и каждый запуск вызывает это сообщение (splat), переполняя кольцевой буфер ядра.

Теперь, когда функция amdgpu_vm_lock_by_pasid() принимает контекст drm_exec, вывод IB был вынесен в отдельную вспомогательную функцию, которая блокирует корневой PD и каждый BO IB совместно с использованием одного ticket drm_exec. Обработка DRM_EXEC_IGNORE_DUPLICATES позволяет корректно обрабатывать IB BO, которые разделяют dma_resv (например, всегда-валидные BO или два IB, поддерживаемые одним и тем же BO). Каждая блокировка теперь является верхнеуровневой операцией acquire в рамках одного ww_acquire_ctx, поэтому условие рекурсивного получения ww_mutex устранено. Также удалена последовательность вызовов amdgpu_bo_reserve()/amdgpu_bo_unref() для каждого IB, включая утечку refcount BO на пути обработки ошибок при сбое amdgpu_bo_reserve().

(cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e)

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

Ответственный

Linux

Резервировать

26.08.2026

Раскрытие

09.09.2026

Модерация

принято

Вход

VDB-401818

EPSS

0.00000

KEV

Нет

Деятельности

Очень низкий

Источники

Do you know our Splunk app?

Download it now for free!