In the Linux kernel, the following vulnerability has been resolved:
drm/xe/guc: Check GuC running state before deregistering exec queue
In normal operation, a registered exec queue is disabled and deregistered through the GuC, and freed only after the GuC confirms completion. However, if the driver is forced to unbind while the exec queue is still running, the user may call execdestroy() after the GuC has already been stopped and CT communication disabled.
In this case, the driver cannot receive a response from the GuC, preventing proper cleanup of exec queue resources. Fix this by directly releasing the resources when GuC is not running.
Here is the failure dmesg log: " [ 468.089581] ---[ end trace 0000000000000000 ]--- [ 468.089608] pci 0000:03:00.0: [drm] ERROR GT0: GUC ID manager unclean (1/65535) [ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535 [ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1 [ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1) [ 468.092716] ------------[ cut here ]------------ [ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xettmvrammgr.c:298 ttmvrammgrfini+0xf8/0x130 [xe] "
v2: use xeucfwisrunning() instead of xegucctenabled(). As CT may go down and come back during VF migration.
(cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea)
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Open-code GGTT MMIO access protection
GGTT MMIO access is currently protected by hotplug (drmdeventer), which works correctly when the driver loads successfully and is later unbound or unloaded. However, if driver load fails, this protection is insufficient because drmdevunplug() is never called.
Additionally, devm release functions cannot guarantee that all BOs with GGTT mappings are destroyed before the GGTT MMIO region is removed, as some BOs may be freed asynchronously by worker threads.
To address this, introduce an open-coded flag, protected by the GGTT lock, that guards GGTT MMIO access. The flag is cleared during the devfiniggtt devm release function to ensure MMIO access is disabled once teardown begins.
(cherry picked from commit 4f3a998a173b4325c2efd90bdadc6ccd3ad9a431)
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Add bounds check on patindex to prevent OOB kernel read in madvise
When user provides a bogus patindex value through the madvise IOCTL, the xepatindexgetcohmode() function performs an array access without validating bounds. This allows a malicious user to trigger an out-of-bounds kernel read from the xe->pat.table array.
The vulnerability exists because the validation in madviseargsaresane() directly calls xepatindexgetcohmode(xe, args->patindex.val) without first checking if patindex is within [0, xe->pat.nentries).
Although xepatindexgetcohmode() has a WARNON to catch this in debug builds, it still performs the unsafe array access in production kernels.
v2(Matthew Auld) - Using arrayindexnospec() to mitigate spectre attacks when the value is used
v3(Matthew Auld) - Put the declarations at the start of the block
(cherry picked from commit 944a3329b05510d55c69c2ef455136e2fc02de29)
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: fix NPD in bomeminfo()
When a buffer object is purged, its ttm.resource is set to NULL via the TTM pipeline gutting flow. However, the BO remains in the client's object list until userspace explicitly closes the GEM handle. If memory stats are queried during this time, accessing bo->ttm.resource->memtype will result in a NULL pointer dereference.
Fix this by safely skipping purged BOs in bomeminfo, as they no longer consume any memory.
User is getting NPD on device resume, and possible theory is that in bomove(), if we need to evict something to SYSTEM to save the CCS state, but the BO is marked as dontneed, this won't trigger a move but will nuke the pages, leaving us with a NULL bo resource. And the meminfo() doesn't look ready to handle a NULL resource.
v2 (Sashiko): - There could potentially be other cases where we might end up with a NULL resource, so make this a general NULL check for now.
(cherry picked from commit c9a8e7daa0afe3161111e27fd92176e608c7f186)