CVE-2024-26939

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

drm/i915/vma: Fix UAF on destroy against retire race

Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle.

[161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915active hint: i915vmaactive+0x0/0x50 [i915] [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debugprintobject+0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CIDRM13375-g003f860e5577+ #1 [161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 [161.360322] Workqueue: i915-unordered _intelwakerefputwork [i915] [161.360592] RIP: 0010:debugprintobject+0x80/0xb0 ... [161.361347] debugobjectfree+0xeb/0x110 [161.361362] i915activefini+0x14/0x130 [i915] [161.361866] releasereferences+0xfe/0x1f0 [i915] [161.362543] i915vmaparked+0x1db/0x380 [i915] [161.363129] _gtpark+0x121/0x230 [i915] [161.363515] intelwakerefput_last+0x1f/0x70 [i915]

That has been tracked down to be happening when another thread is deactivating the VMA inside _activeretire() helper, after the VMA's active counter has been already decremented to 0, but before deactivation of the VMA's object is reported to the object debugging tool.

We could prevent from that race by serializing i915activefini() with _activeretire() via ref->treelock, but that wouldn't stop the VMA from being used, e.g. from _i915vmaretire() called at the end of _activeretire(), after that VMA has been already freed by a concurrent i915vmadestroy() on return from the i915activefini(). Then, we should rather fix the issue at the VMA level, not in i915_active.

Since _i915vmaparked() is called from _gtpark() on last put of the GT's wakeref, the issue could be addressed by holding the GT wakeref long enough for _active_retire() to complete before that wakeref is released and the GT parked.

I believe the issue was introduced by commit d93939730347 ("drm/i915: Remove the vma refcount") which moved a call to i915activefini() from a dropped i915vmarelease(), called on last put of the removed VMA kref, to i915vmaparked() processing path called on last put of a GT wakeref. However, its visibility to the object debugging tool was suppressed by a bug in i915_active that was fixed two weeks later with commit e92eb246feb9 ("drm/i915/active: Fix missing debug object activation").

A VMA associated with a request doesn't acquire a GT wakeref by itself. Instead, it depends on a wakeref held directly by the request's active intelcontext for a GT associated with its VM, and indirectly on that intelcontext's engine wakeref if the engine belongs to the same GT as the VMA's VM. Those wakerefs are released asynchronously to VMA deactivation.

Fix the issue by getting a wakeref for the VMA's GT when activating it, and putting that wakeref only after the VMA is deactivated. However, exclude global GTT from that processing path, otherwise the GPU never goes idle. Since _i915vma_retire() may be called from atomic contexts, use async variant of wakeref put. Also, to avoid circular locking dependency, take care of acquiring the wakeref before VM mutex when both are needed.

v7: Add inline comments with justifications for: - using untracked variants of intelgtpmget/put() (Nirmoy), - using async variant of _put(), - not getting the wakeref in case of a global GTT, - always getting the first wakeref outside vm->mutex. v6: Since _i915vmaactive/retire() callbacks are not serialized, storing a wakeref tracking handle inside struct i915vma is not safe, and there is no other good place for that. Use untracked variants of intelgtpmget/put_async(). v5: Replace "tile" with "GT" across commit description (Rodrigo), - ---truncated---