Linux kernel (drivers/gpu/drm/xe): The preempt-fence lock lives inside the exec queue, but the queue reference is

Impact

The preempt-fence lock lives inside the exec queue, but the queue reference is dropped as soon as the fence is signalled. A waiter woken afterwards takes a lock inside already-freed memory - a use-after-free of driver state driven by ordinary long-running-queue and VM-bind traffic, and a foothold for kernel memory corruption from a tenant container.

Who can reach it

Tenant holding /dev/dri/renderD* on Intel xe using long-running exec queues or VM binds (i.e. any compute workload): race queue teardown against a thread waiting on the preempt fence. Multiple independent reproducers are referenced in the upstream fix.

What to do

Update to a kernel carrying the fix (stable commits below; no fixed_in published). No selective interim control - preempt fences are on the normal LR/compute submission path.

References

Related entries

• Linux kernel (drivers/gpu/drm/xe): The per-client memory accounting walks buffer-object state (TTM resource, tt pages)CVE-2024-46866 · Linux kernel (drivers/gpu/drm/xe)High
• Linux kernel (drivers/gpu/drm/xe): The GPU VM is published into the id table before the create ioctl finishes with itCVE-2024-49865 · Linux kernel (drivers/gpu/drm/xe)High
• Linux kernel (drivers/gpu/drm/xe): The observation/OA path reuses one batch buffer and appends a batch-end command onCVE-2024-50090 · Linux kernel (drivers/gpu/drm/xe)High
• 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