CVE-2025-37907
accel/ivpu: Fix locking order in ivpu_job_submit
We use these services and cookies to improve your user experience. You may opt out if you wish, however, this may limit some features on this site.
Please see our statement on Data Privacy.
accel/ivpu: Fix locking order in ivpu_job_submit
In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix locking order in ivpu_job_submit Fix deadlock in job submission and abort handling. When a thread aborts currently executing jobs due to a fault, it first locks the global lock protecting submitted_jobs (#1). After the last job is destroyed, it proceeds to release the related context and locks file_priv (#2). Meanwhile, in the job submission thread, the file_priv lock (#2) is taken first, and then the submitted_jobs lock (#1) is obtained when a job is added to the submitted jobs list. CPU0 CPU1 ---- ---- (for example due to a fault) (jobs submissions keep coming) lock(&vdev->submitted_jobs_lock) #1 ivpu_jobs_abort_all() job_destroy() lock(&file_priv->lock) #2 lock(&vdev->submitted_jobs_lock) #1 file_priv_release() lock(&vdev->context_list_lock) lock(&file_priv->lock) #2 This order of locking causes a deadlock. To resolve this issue, change the order of locking in ivpu_job_submit().
Reserved 2025-04-16 | Published 2025-05-20 | Updated 2025-05-26 | Assigner Linuxgit.kernel.org/...c/079d2622f8c9e0c380149645fff21d35c59ce6ff
git.kernel.org/...c/b9b70924a272c2d72023306bc56f521c056212ee
git.kernel.org/...c/ab680dc6c78aa035e944ecc8c48a1caab9f39924
Support options
