Description

In the Linux kernel, the following vulnerability has been resolved: drm/msm: RCU-free the scheduler-containing ring and VM objects Both struct msm_ringbuffer and struct msm_gem_vm embed a struct drm_gpu_scheduler. msm_ringbuffer_destroy() and the VM free callback msm_gem_vm_free() call drm_sched_fini() on the embedded scheduler and then free the containing object with plain kfree(). drm_sched_fence_get_timeline_name() returns fence->sched->name, and the scheduler fence keeps a .release callback so it is not ops-detached on signalling. A finished fence exported to userspace (the submit out-fence, or a VM_BIND fence, via sync_file / drm_syncobj) keeps pointing at the embedded scheduler after the ring/VM is freed, so a later get_timeline_name() -- reachable unprivileged through SYNC_IOC_FILE_INFO -- dereferences freed slab memory (KASAN slab-use-after-free read). Per the dma-fence lifetime contract the exporter must keep the data backing a signalled fence alive for an RCU grace period. Free the scheduler-containing objects with kfree_rcu() instead of kfree(). Patchwork: https://patchwork.freedesktop.org/patch/750234/

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-10-06T09:18:01.617Z",
  "pubdate": "2026-10-06T09:18:01.617Z",
  "executiveSummary": "This vulnerability is a Use-After-Free (UAF) flaw residing in the Linux kernel's drm/msm driver, specifically affecting memory management of GPU scheduler objects.\nThe issue stems from the premature deallocation of struct msm_ringbuffer and struct msm_gem_vm objects, which contain an embedded drm_gpu_scheduler.\nThe impact allows an unprivileged local attacker to trigger a kernel-space slab-use-after-free read.\nThis occurs because exported dma-fences maintain references to the scheduler after the parent objects have been freed, violating the dma-fence lifetime contract.\nSuccessful exploitation could lead to information disclosure, kernel memory corruption, or system instability.\nExploitation is accessible to unprivileged users via standard syscall interfaces such as SYNC_IOC_FILE_INFO.\nRisk is significant due to the ease of reachability within the GPU driver subsystem, necessitating prompt application of RCU-based memory management fixes.",
  "technicalDetails": "The root cause is a violation of the dma-fence lifetime contract within the msm (Mobile Station Modem) DRM driver. Both struct msm_ringbuffer and struct msm_gem_vm structures contain a drm_gpu_scheduler instance.\nIn the original implementation, msm_ringbuffer_destroy() and msm_gem_vm_free() invoked drm_sched_fini() followed by an immediate kfree() of the parent structure. This process fails to account for the fact that dma-fences, once exported to userspace (e.g., via sync_file or drm_syncobj as submit out-fences or VM_BIND fences), persist beyond the destruction of the parent scheduler object.\nThe dma-fence structure keeps a .release callback and remains ops-attached even after signaling. When userspace interacts with these fences via the SYNC_IOC_FILE_INFO ioctl, the kernel executes drm_sched_fence_get_timeline_name(). This function dereferences fence->sched->name.\nBecause the underlying memory for the scheduler object was freed by kfree() before the fence was fully retired or cleaned up, the kernel attempts to read from slab memory that has already been returned to the allocator. This triggers a KASAN slab-use-after-free read error.\nThe attack flow involves: 1) Establishing a GPU context that utilizes msm_ringbuffer or msm_gem_vm. 2) Triggering operations that create exported dma-fences. 3) Orchestrating the destruction of the parent objects while the fences remain active in userspace. 4) Invoking SYNC_IOC_FILE_INFO to trigger the dereference of the dangling pointer within the kernel context.\nThis vulnerability does not require special network exposure, as the interface is local. It does not require elevated privileges, as unprivileged users can interact with the DRM subsystem to initiate fence creation and query information. The post-exploitation impact could potentially allow for kernel memory introspection or, with further primitive chaining, control flow hijacking or privilege escalation."
}