Linux kernel (drivers/gpu/drm/xe): The observation/OA path reuses one batch buffer and appends a batch-end command on

Impact

The observation/OA path reuses one batch buffer and appends a batch-end command on every reconfiguration, so repeated use runs the write past the end of the allocation. The kernel overwrites adjacent memory and the GPU then executes whatever follows the batch - kernel heap corruption driven entirely from userspace, plus GPU-side execution of unintended commands.

Who can reach it

Tenant holding /dev/dri/renderD* on Intel xe opens an observation (OA) stream against its own exec queue and repeatedly reconfigures the same metric set. Per-queue OA does not require CAP_PERFMON, so this is reachable from an ordinary tenant container.

What to do

Update to a kernel carrying the fix (stable commits below; no fixed_in published). Interim: set perf_stream_paranoid to block observation streams, or deny the xe observation ioctl to tenant workloads.

References

Related entries

• Linux kernel (drivers/gpu/drm/xe): Xe freed a job from inside timeout-detection-and-recovery while the submissionCVE-2024-50149 · Linux kernel (drivers/gpu/drm/xe)High
• Linux kernel (drivers/gpu/drm/xe): A tenant that suspends an exec queue and then closes it while the GuCCVE-2024-56552 · Linux kernel (drivers/gpu/drm/xe)High
• 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