ghsa-w6fj-6wrc-6vhr
Vulnerability from github
Published
2024-09-13 06:30
Modified
2024-09-13 18:31
Details

In the Linux kernel, the following vulnerability has been resolved:

drm/xe: prevent UAF around preempt fence

The fence lock is part of the queue, therefore in the current design anything locking the fence should then also hold a ref to the queue to prevent the queue from being freed.

However, currently it looks like we signal the fence and then drop the queue ref, but if something is waiting on the fence, the waiter is kicked to wake up at some later point, where upon waking up it first grabs the lock before checking the fence state. But if we have already dropped the queue ref, then the lock might already be freed as part of the queue, leading to uaf.

To prevent this, move the fence lock into the fence itself so we don't run into lifetime issues. Alternative might be to have device level lock, or only release the queue in the fence release callback, however that might require pushing to another worker to avoid locking issues.

References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2454 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2342 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2020 (cherry picked from commit 7116c35aacedc38be6d15bd21b2fc936eed0008b)

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-46683"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-13T06:15:12Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: prevent UAF around preempt fence\n\nThe fence lock is part of the queue, therefore in the current design\nanything locking the fence should then also hold a ref to the queue to\nprevent the queue from being freed.\n\nHowever, currently it looks like we signal the fence and then drop the\nqueue ref, but if something is waiting on the fence, the waiter is\nkicked to wake up at some later point, where upon waking up it first\ngrabs the lock before checking the fence state. But if we have already\ndropped the queue ref, then the lock might already be freed as part of\nthe queue, leading to uaf.\n\nTo prevent this, move the fence lock into the fence itself so we don\u0027t\nrun into lifetime issues. Alternative might be to have device level\nlock, or only release the queue in the fence release callback, however\nthat might require pushing to another worker to avoid locking issues.\n\nReferences: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2454\nReferences: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2342\nReferences: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2020\n(cherry picked from commit 7116c35aacedc38be6d15bd21b2fc936eed0008b)",
  "id": "GHSA-w6fj-6wrc-6vhr",
  "modified": "2024-09-13T18:31:46Z",
  "published": "2024-09-13T06:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46683"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/10081b0b0ed201f53e24bd92deb2e0f3c3e713d4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/730b72480e29f63fd644f5fa57c9d46109428953"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}


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.