Linux kernel (drivers/gpu/drm/xe): A tenant's jobs can occupy the same copy engines the driver needs to service GPU

Impact

A tenant's jobs can occupy the same copy engines the driver needs to service GPU page faults, and the GuC scheduling queue is only two deep. The migration path ends up waiting behind a fault it is itself required to resolve, the GPU deadlocks, and every tenant sharing that device stops making progress until the node is reset.

Who can reach it

Tenant container holding /dev/dri/renderD* on an Intel xe device with recoverable GPU page faults enabled (USM/SVM platforms): submit sustained blitter (BCS) work so user jobs and the migration queue contend for the same engine instances. No capabilities required.

What to do

Update to a kernel carrying the fix (stable commits below; no fixed_in published). Interim: disable recoverable page faults / USM on shared xe devices, or give each tenant its own device rather than sharing engines.

References

Related entries

• Linux kernel (drivers/gpu/drm/xe): Same per-client accounting path, different failure - if the fdinfo read drops theCVE-2024-46867 · Linux kernel (drivers/gpu/drm/xe)Medium
• Linux kernel (drivers/gpu/drm/xe): User VM_BIND work is scheduled onto engines that can themselves take page faultsCVE-2024-47729 · Linux kernel (drivers/gpu/drm/xe)Medium
• Linux kernel (drivers/gpu/drm/xe): Passing a sync object that fails fence lookup makes the exec ioctl return toCVE-2024-53086 · Linux kernel (drivers/gpu/drm/xe)Medium
• Linux kernel (drivers/gpu/drm/xe): Every exec ioctl that bails on an input-validation error leaves an exec-queueCVE-2024-53087 · Linux kernel (drivers/gpu/drm/xe)Medium
• Linux kernel (drivers/gpu/drm/xe): The migration copy path falls back to a stack bounce buffer when the tenant's bufferCVE-2025-38690 · Linux kernel (drivers/gpu/drm/xe)Medium
• Linux kernel (drivers/gpu/drm/xe): On SR-IOV-partitioned Intel GPUs, the local-memory translation tables handed to a VFCVE-2025-38511 · Linux kernel (drivers/gpu/drm/xe)High