{"id":"DEBIAN-CVE-2024-41092","details":"In 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:  \u003c6\u003e [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence ... \u003c6\u003e [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled \u003c6\u003e [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled \u003c3\u003e [414.070354] Unable to pin Y-tiled fence; err:-4 \u003c3\u003e [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence-\u003eactive)) ... \u003c4\u003e[  609.603992] ------------[ cut here ]------------ \u003c2\u003e[  609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! \u003c4\u003e[  609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI \u003c4\u003e[  609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G     U  W          6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 \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 \u003c4\u003e[  609.604010] Workqueue: i915 __i915_gem_free_work [i915] \u003c4\u003e[  609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... \u003c4\u003e[  609.604271] Call Trace: \u003c4\u003e[  609.604273]  \u003cTASK\u003e ... \u003c4\u003e[  609.604716]  __i915_vma_evict+0x2e9/0x550 [i915] \u003c4\u003e[  609.604852]  __i915_vma_unbind+0x7c/0x160 [i915] \u003c4\u003e[  609.604977]  force_unbind+0x24/0xa0 [i915] \u003c4\u003e[  609.605098]  i915_vma_destroy+0x2f/0xa0 [i915] \u003c4\u003e[  609.605210]  __i915_gem_object_pages_fini+0x51/0x2f0 [i915] \u003c4\u003e[  609.605330]  __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] \u003c4\u003e[  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-\u003eactive via fence_update().   That commit introduced vma-\u003efence-\u003eactive in order for the fence_update() to be able to wait selectively on that one instead of vma-\u003eactive 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-\u003eactive)) in front. No justification was provided on why we might then expect idleness of vma-\u003efence-\u003eactive 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-\u003efence-\u003eactive in i915_vma_revoke_fence().  (cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)","modified":"2026-09-15T09:03:09.787757855Z","published":"2024-07-29T16:15:04.383Z","upstream":["CVE-2024-41092"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2024-41092"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:12","purl":"pkg:deb/debian/linux?arch=source&distro=bookworm"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.98-1"}]}],"versions":["6.1.27-1","6.1.37-1","6.1.38-1","6.1.38-2","6.1.38-2~bpo11+1","6.1.38-3","6.1.38-4","6.1.38-4~bpo11+1","6.1.52-1","6.1.55-1","6.1.55-1~bpo11+1","6.1.64-1","6.1.66-1","6.1.67-1","6.1.69-1","6.1.69-1~bpo11+1","6.1.76-1","6.1.76-1~bpo11+1","6.1.82-1","6.1.85-1","6.1.90-1","6.1.90-1~bpo11+1","6.1.94-1","6.1.94-1~bpo11+1"],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2024-41092.json"}},{"package":{"name":"linux","ecosystem":"Debian:13","purl":"pkg:deb/debian/linux?arch=source&distro=trixie"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.9.8-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2024-41092.json"}},{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.9.8-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2024-41092.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}]}