Linux kernel (drivers/gpu/drm/xe): Freeing a scheduler job dereferences the VM it belongs to, but the final exec-queue

Impact

Freeing a scheduler job dereferences the VM it belongs to, but the final exec-queue put that happens first can already have destroyed that VM. The result is a use-after-free on the scheduler job path, reachable from an ordinary submit-then-close sequence inside a tenant container.

Who can reach it

Tenant holding /dev/dri/renderD* on Intel xe: submit jobs, then destroy the exec queue and VM so the last reference drops while jobs are still being freed. Unprivileged; the ordering is under the tenant's control.

What to do

Update to a kernel carrying the fix (stable commits below; no fixed_in published). No interim control - this is the standard submission teardown path.

References

Related entries

• Linux kernel (drivers/gpu/drm/xe): The preempt-fence lock lives inside the exec queue, but the queue reference isCVE-2024-46683 · Linux kernel (drivers/gpu/drm/xe)High
• 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