CVE-2024-26939

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/vma: Fix UAF on destroy against retire race<br /> <br /> Object debugging tools were sporadically reporting illegal attempts to<br /> free a still active i915 VMA object when parking a GT believed to be idle.<br /> <br /> [161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]<br /> [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0<br /> ...<br /> [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1<br /> [161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022<br /> [161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915]<br /> [161.360592] RIP: 0010:debug_print_object+0x80/0xb0<br /> ...<br /> [161.361347] debug_object_free+0xeb/0x110<br /> [161.361362] i915_active_fini+0x14/0x130 [i915]<br /> [161.361866] release_references+0xfe/0x1f0 [i915]<br /> [161.362543] i915_vma_parked+0x1db/0x380 [i915]<br /> [161.363129] __gt_park+0x121/0x230 [i915]<br /> [161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915]<br /> <br /> That has been tracked down to be happening when another thread is<br /> deactivating the VMA inside __active_retire() helper, after the VMA&amp;#39;s<br /> active counter has been already decremented to 0, but before deactivation<br /> of the VMA&amp;#39;s object is reported to the object debugging tool.<br /> <br /> We could prevent from that race by serializing i915_active_fini() with<br /> __active_retire() via ref-&gt;tree_lock, but that wouldn&amp;#39;t stop the VMA from<br /> being used, e.g. from __i915_vma_retire() called at the end of<br /> __active_retire(), after that VMA has been already freed by a concurrent<br /> i915_vma_destroy() on return from the i915_active_fini(). Then, we should<br /> rather fix the issue at the VMA level, not in i915_active.<br /> <br /> Since __i915_vma_parked() is called from __gt_park() on last put of the<br /> GT&amp;#39;s wakeref, the issue could be addressed by holding the GT wakeref long<br /> enough for __active_retire() to complete before that wakeref is released<br /> and the GT parked.<br /> <br /> I believe the issue was introduced by commit d93939730347 ("drm/i915:<br /> Remove the vma refcount") which moved a call to i915_active_fini() from<br /> a dropped i915_vma_release(), called on last put of the removed VMA kref,<br /> to i915_vma_parked() processing path called on last put of a GT wakeref.<br /> However, its visibility to the object debugging tool was suppressed by a<br /> bug in i915_active that was fixed two weeks later with commit e92eb246feb9<br /> ("drm/i915/active: Fix missing debug object activation").<br /> <br /> A VMA associated with a request doesn&amp;#39;t acquire a GT wakeref by itself.<br /> Instead, it depends on a wakeref held directly by the request&amp;#39;s active<br /> intel_context for a GT associated with its VM, and indirectly on that<br /> intel_context&amp;#39;s engine wakeref if the engine belongs to the same GT as the<br /> VMA&amp;#39;s VM. Those wakerefs are released asynchronously to VMA deactivation.<br /> <br /> Fix the issue by getting a wakeref for the VMA&amp;#39;s GT when activating it,<br /> and putting that wakeref only after the VMA is deactivated. However,<br /> exclude global GTT from that processing path, otherwise the GPU never goes<br /> idle. Since __i915_vma_retire() may be called from atomic contexts, use<br /> async variant of wakeref put. Also, to avoid circular locking dependency,<br /> take care of acquiring the wakeref before VM mutex when both are needed.<br /> <br /> v7: Add inline comments with justifications for:<br /> - using untracked variants of intel_gt_pm_get/put() (Nirmoy),<br /> - using async variant of _put(),<br /> - not getting the wakeref in case of a global GTT,<br /> - always getting the first wakeref outside vm-&gt;mutex.<br /> v6: Since __i915_vma_active/retire() callbacks are not serialized, storing<br /> a wakeref tracking handle inside struct i915_vma is not safe, and<br /> there is no other good place for that. Use untracked variants of<br /> intel_gt_pm_get/put_async().<br /> v5: Replace "tile" with "GT" across commit description (Rodrigo),<br /> - <br /> ---truncated---