CVE-2025-40096 in Linux
Сводка
по VulDB • 03.06.2026
В ядре Linux устранена следующая уязвимость:
drm/sched: Исправлена потенциальная двойная свобода (double free) в функции drm_sched_job_add_resv_dependencies
При добавлении зависимостей с помощью функции drm_sched_job_add_dependency(), эта функция освобождает ссылку на fence как при успешном выполнении, так и при ошибке. Следовательно, вызов dma_fence_put() на пути обработки ошибки (когда не удалось расширить xarray) приводит к двойной свободе памяти.
Интересно, что этот баг присутствовал с самого момента коммита ebd5f74255b9 («drm/sched: Add dependency tracking»), поскольку код тогда выглядел следующим образом:
```c drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) {
ret = drm_sched_job_add_dependency(job, fences[i]);
if (ret) break; }
for (; i < fence_count; i++) dma_fence_put(fences[i]);
```
Это означает, что для неудачного индекса 'i' вызов dma_fence_put() уже являлся двойной свободой. Возможно, в то время не было пользователей или тестовые случаи были недостаточными для воспроизведения этой ошибки.
Баг был замечен и исправлен только после того, как появился коммит 9c2ba265352a («drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2»), который содержал исправление для коммита 4eaf02d6076c («drm/scheduler: fix drm_sched_job_add_implicit_dependencies»).
В тот момент это была слегка иная вариация двойной свободы, которую заметил и попытался исправить коммит 963d0b356935 («drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder»).
Однако ошибка не исчезла, а лишь переместилась из внутренней части функции drm_sched_job_add_dependency(), где происходило освобождение ссылки, которая еще не была получена, к вызывающей стороне, когда происходит повторное освобождение ссылки, уже ранее освобожденной предыдущей функцией в случае ошибки.
Поэтому несложно определить правильную цель для тега fixes (fixes tag), поэтому давайте оставим все просто и продолжим цепочку исправлений.
При внесении исправления мы также улучшили комментарий и объяснили причину взятия ссылки без ее последующего освобождения.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.