Linux kernel (drivers/gpu/drm/xe): A tenant that suspends an exec queue and then closes it while the GuC

Impact

A tenant that suspends an exec queue and then closes it while the GuC scheduling-disable is still in flight desynchronises the driver's view of GuC state - the late response deregisters a queue that was never marked for destruction. That corrupts submission state for the whole GT (affecting co-tenants sharing the engine) and leaves the queue object referenced after teardown.

Who can reach it

Tenant container holding /dev/dri/renderD* on Intel xe: request suspend on an exec queue, then kill/close it before the GuC round-trip completes. Timing is easy to win - the trace in the fix shows the whole window is under a millisecond and it reproduces in ordinary test runs.

What to do

Update to a kernel carrying the fix (stable commits below; no fixed_in published). No practical interim control - exec queue suspend and close are core submission ioctls.

References

Related entries

• Linux kernel (drivers/gpu/drm/xe): Xe built its scatter-gather table from HMM page pointers without holding theCVE-2025-21939 · Linux kernel (drivers/gpu/drm/xe)High
• Linux kernel (drivers/gpu/drm/xe): A GPU TLB invalidation for a very large address range computes its length with aCVE-2025-37761 · Linux kernel (drivers/gpu/drm/xe)High
• Linux kernel (drivers/gpu/drm/xe): The error path of the Xe VRAM clear helper waits on a fence pointer that is onlyCVE-2025-37869 · Linux kernel (drivers/gpu/drm/xe)High
• Linux kernel (drivers/gpu/drm/xe): Xe frees data that its exported dma-fences still point at - notably the timelineCVE-2025-38703 · Linux kernel (drivers/gpu/drm/xe)High
• Linux kernel (drivers/gpu/drm/xe): A tenant that submits a deliberately malformed array bind to the Xe VM_BIND ioctlCVE-2025-38731 · Linux kernel (drivers/gpu/drm/xe)High
• Linux kernel (drivers/gpu/drm/xe): On the migration error path the previous fence is released before the code waits onCVE-2025-39740 · Linux kernel (drivers/gpu/drm/xe)High