DRM scheduler fix closes unprivileged GPU fence UAF read

A use-after-free read in the Linux kernel's shared DRM GPU scheduler can let unprivileged userspace touch freed kernel memory through finished fences still held after a driver tears down its scheduler, according to a fix from Jonghyuk Kim.

The scheduler reports a fence's timeline name by walking a pointer back into the live drm_gpu_scheduler object. Several drivers allocate that scheduler per context, queue, or VM and free it on ordinary fd or context teardown, while still exporting completed fences to userspace through sync files or syncobjs. Because those fences keep a release callback, they are not detached on signal, so a later unprivileged SYNC_IOC_FILE_INFO query can call into get_timeline_name against a scheduler that is already gone. Kim describes the result as a deterministic slab use-after-free read; once the slab is reclaimed it becomes a bounded arbitrary kernel read. There is no write primitive on this path.

The same pattern already produced CVE-2025-38703 in drm/xe and CVE-2025-71302 in drm/panthor, both fixed only in those drivers. amdxdna, nouveau, and msm (VM_BIND) remained exposed in mainline. Kim's change caches the timeline name string when the fence is created, while the scheduler is still alive, and returns that cached pointer afterward. Scheduler names are persistent string literals, so the core fix covers every per-context scheduler driver at once rather than chasing each one.

A companion KUnit test on the existing mock harness holds a finished fence, frees the mock scheduler, then queries the timeline name, catching the UAF under KASAN with no hardware. The series is aimed at current mainline and flagged as a stable backport candidate. With the bug class already public through the earlier CVEs, Kim sent the patches directly to the linux-kernel list instead of the private security process.