fkie_cve-2025-37907
Vulnerability from fkie_nvd
Published
2025-05-20 16:15
Modified
2025-05-21 20:25
Severity ?
Summary
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().
Impacted products
Vendor Product Version



{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix locking order in ivpu_job_submit\n\nFix deadlock in job submission and abort handling.\nWhen a thread aborts currently executing jobs due to a fault,\nit first locks the global lock protecting submitted_jobs (#1).\n\nAfter the last job is destroyed, it proceeds to release the related context\nand locks file_priv (#2). Meanwhile, in the job submission thread,\nthe file_priv lock (#2) is taken first, and then the submitted_jobs\nlock (#1) is obtained when a job is added to the submitted jobs list.\n\n       CPU0                            CPU1\n       ----                    \t       ----\n  (for example due to a fault)         (jobs submissions keep coming)\n\n  lock(\u0026vdev-\u003esubmitted_jobs_lock) #1\n  ivpu_jobs_abort_all()\n  job_destroy()\n                                      lock(\u0026file_priv-\u003elock)           #2\n                                      lock(\u0026vdev-\u003esubmitted_jobs_lock) #1\n  file_priv_release()\n  lock(\u0026vdev-\u003econtext_list_lock)\n  lock(\u0026file_priv-\u003elock)           #2\n\nThis order of locking causes a deadlock. To resolve this issue,\nchange the order of locking in ivpu_job_submit()."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: accel/ivpu: Se corrige el orden de bloqueo en ivpu_job_submit. Se corrige el bloqueo en el env\u00edo de trabajos y la gesti\u00f3n de abortos. Cuando un hilo cancela trabajos en ejecuci\u00f3n debido a un fallo, primero bloquea el bloqueo global que protege submit_jobs (#1). Tras la destrucci\u00f3n del \u00faltimo trabajo, libera el contexto relacionado y bloquea file_priv (#2). Mientras tanto, en el hilo de env\u00edo de trabajos, primero se obtiene el bloqueo file_priv (#2) y, a continuaci\u00f3n, el bloqueo submit_jobs (#1) al a\u00f1adir un trabajo a la lista de trabajos enviados. CPU0 CPU1 ---- ---- (por ejemplo, debido a un fallo) (los env\u00edos de trabajos siguen llegando) lock(\u0026amp;vdev-\u0026gt;submitted_jobs_lock) #1 ivpu_jobs_abort_all() job_destroy() lock(\u0026amp;file_priv-\u0026gt;lock) #2 lock(\u0026amp;vdev-\u0026gt;submitted_jobs_lock) #1 file_priv_release() lock(\u0026amp;vdev-\u0026gt;context_list_lock) lock(\u0026amp;file_priv-\u0026gt;lock) #2 Este orden de bloqueo provoca un interbloqueo. Para solucionar este problema, cambie el orden de bloqueo en ivpu_job_submit()."
    }
  ],
  "id": "CVE-2025-37907",
  "lastModified": "2025-05-21T20:25:16.407",
  "metrics": {},
  "published": "2025-05-20T16:15:27.177",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/079d2622f8c9e0c380149645fff21d35c59ce6ff"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/ab680dc6c78aa035e944ecc8c48a1caab9f39924"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/b9b70924a272c2d72023306bc56f521c056212ee"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…