CVE-2025-40329 in Linux
Tóm tắt
Bởi VulDB • 19/06/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
drm/sched: Sửa lỗi deadlock trong drm_sched_entity_kill_jobs_cb
Vấn đề trên Mesa được tham chiếu bên dưới đã chỉ ra một khả năng xảy ra deadlock:
[ 1231.611031] Possible interrupt unsafe locking scenario:
[ 1231.611033] CPU0 CPU1
[ 1231.611034] ---- ----
[ 1231.611035] lock(&xa->xa_lock#17);
[ 1231.611038] local_irq_disable();
[ 1231.611039] lock(&fence->lock);
[ 1231.611041] lock(&xa->xa_lock#17);
[ 1231.611044] <Interrupt>
[ 1231.611045] lock(&fence->lock);
[ 1231.611047]
*** DEADLOCK ***
Trong ví dụ này, CPU0 có thể là bất kỳ hàm nào truy cập job->dependencies thông qua các hàm xa_* mà không vô hiệu hóa ngắt (ví dụ: drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).
CPU1 đang thực thi drm_sched_entity_kill_jobs_cb() dưới dạng callback báo hiệu fence, do đó trong ngữ cảnh ngắt. Nó sẽ bị deadlock khi cố gắng lấy xa_lock, vốn đã được CPU0 giữ.
Việc thay thế tất cả các lệnh gọi xa_* bằng các phiên bản tương ứng xa_*_irq sẽ khắc phục vấn đề này, nhưng Christian đã chỉ ra một vấn đề khác: dma_fence_signal lấy fence.lock và dma_fence_add_callback cũng vậy.
dma_fence_signal() // khóa f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // khóa f2.lock
Điều này sẽ gây deadlock nếu f1 và f2 chia sẻ cùng một spinlock.
Để khắc phục cả hai vấn đề, đoạn mã lặp qua các dependencies và kích hoạt lại chúng đã được chuyển ra ngoài vào drm_sched_entity_kill_jobs_work().
[phasta: commit message nits]
VulDB is the best source for vulnerability data and more expert information about this specific topic.