GHSA-6FVV-3VW6-WP7C
Vulnerability from github – Published: 2024-07-29 18:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Fix potential UAF by revoke of fence registers
CI has been sporadically reporting the following issue triggered by igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
<6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence ... <6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled <3> [414.070354] Unable to pin Y-tiled fence; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cut here ]------------ <2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 <4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915] <4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Call Trace: <4>[ 609.604273] ... <4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440] process_scheduled_works+0x351/0x690 ...
In the past, there were similar failures reported by CI from other IGT tests, observed on other platforms.
Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for idleness of vma->active via fence_update(). That commit introduced vma->fence->active in order for the fence_update() to be able to wait selectively on that one instead of vma->active since only idleness of fence registers was needed. But then, another commit 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to fence_update() in i915_vma_revoke_fence() with only fence_write(), and also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front. No justification was provided on why we might then expect idleness of vma->fence->active without first waiting on it.
The issue can be potentially caused by a race among revocation of fence registers on one side and sequential execution of signal callbacks invoked on completion of a request that was using them on the other, still processed in parallel to revocation of those fence registers. Fix it by waiting for idleness of vma->fence->active in i915_vma_revoke_fence().
(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)
{
"affected": [],
"aliases": [
"CVE-2024-41092"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-29T16:15:04Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gt: Fix potential UAF by revoke of fence registers\n\nCI has been sporadically reporting the following issue triggered by\nigt@i915_selftest@live@hangcheck on ADL-P and similar machines:\n\n\u003c6\u003e [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence\n...\n\u003c6\u003e [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled\n\u003c6\u003e [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled\n\u003c3\u003e [414.070354] Unable to pin Y-tiled fence; err:-4\n\u003c3\u003e [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(\u0026fence-\u003eactive))\n...\n\u003c4\u003e[ 609.603992] ------------[ cut here ]------------\n\u003c2\u003e[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!\n\u003c4\u003e[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n\u003c4\u003e[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1\n\u003c4\u003e[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023\n\u003c4\u003e[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]\n\u003c4\u003e[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]\n...\n\u003c4\u003e[ 609.604271] Call Trace:\n\u003c4\u003e[ 609.604273] \u003cTASK\u003e\n...\n\u003c4\u003e[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]\n\u003c4\u003e[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]\n\u003c4\u003e[ 609.604977] force_unbind+0x24/0xa0 [i915]\n\u003c4\u003e[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]\n\u003c4\u003e[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]\n\u003c4\u003e[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]\n\u003c4\u003e[ 609.605440] process_scheduled_works+0x351/0x690\n...\n\nIn the past, there were similar failures reported by CI from other IGT\ntests, observed on other platforms.\n\nBefore commit 63baf4f3d587 (\"drm/i915/gt: Only wait for GPU activity\nbefore unbinding a GGTT fence\"), i915_vma_revoke_fence() was waiting for\nidleness of vma-\u003eactive via fence_update(). That commit introduced\nvma-\u003efence-\u003eactive in order for the fence_update() to be able to wait\nselectively on that one instead of vma-\u003eactive since only idleness of\nfence registers was needed. But then, another commit 0d86ee35097a\n(\"drm/i915/gt: Make fence revocation unequivocal\") replaced the call to\nfence_update() in i915_vma_revoke_fence() with only fence_write(), and\nalso added that GEM_BUG_ON(!i915_active_is_idle(\u0026fence-\u003eactive)) in front.\nNo justification was provided on why we might then expect idleness of\nvma-\u003efence-\u003eactive without first waiting on it.\n\nThe issue can be potentially caused by a race among revocation of fence\nregisters on one side and sequential execution of signal callbacks invoked\non completion of a request that was using them on the other, still\nprocessed in parallel to revocation of those fence registers. Fix it by\nwaiting for idleness of vma-\u003efence-\u003eactive in i915_vma_revoke_fence().\n\n(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)",
"id": "GHSA-6fvv-3vw6-wp7c",
"modified": "2025-11-04T00:31:04Z",
"published": "2024-07-29T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41092"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/06dec31a0a5112a91f49085e8a8fa1a82296d5c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/29c0fdf49078ab161570d3d1c6e13d66f182717d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/414f4a31f7a811008fd9a33b06216b060bad18fc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/996c3412a06578e9d779a16b9e79ace18125ab50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ca0fabd365a27a94a36e68a7a02df8ff3c13dac6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f771b91f21c46ad1217328d05e72a2c7e3add535"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"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"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.