DRM scheduler core plugs fence timeline use-after-free

A core fix is headed into the Linux DRM job scheduler for a slab use-after-free that let unprivileged userspace touch freed GPU scheduler memory through fence timeline name queries.

Drivers that allocate a scheduler per context, queue, or VM free that object when the context is torn down. The finished fence can outlive it: userspace can hold an exported fence through a sync file or DRM sync object and later ask for its timeline name, for example via SYNC_IOC_FILE_INFO. That path dereferenced the scheduler name on already-freed memory. Once the slab was re-sprayed, the same read became an information leak.

The flaw is the same class as CVE-2025-38703 in drm/xe and CVE-2025-71302 in drm/panthor, both fixed earlier on a per-driver basis. Jonghyuk Kim reports that amdxdna, nouveau, and msm's VM_BIND path remain exposed in mainline, and the series closes the hole once in the scheduler core rather than chasing each driver.

Earlier revisions cached the timeline name at fence init. Review found that incomplete: the documented contract does not require the name passed at scheduler setup to outlive the scheduler, and drivers with dynamically allocated names still UAFed on the string. The fix instead drops the finished fence's release callback. With neither release nor wait, dma-fence detaches ops on signalling, so timeline name lookups return a static string and never reach the dangling scheduler pointer. Reference handling that the callback used to perform moves elsewhere so the finished fence still frees cleanly.

A KUnit regression test on the mock scheduler under KASAN reproduces the old path and confirms the fix.