In the Linux kernel, the following vulnerability has been resolved: drm/msm: RCU-free the…

Why it is Yellow

• CVSS 7.1 high
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/01c8d1f385f788f1bbbbb7687c4386d614281218
• https://git.kernel.org/stable/c/713abac5c04ccbae67f9ac68c3921845535388e7
• https://git.kernel.org/stable/c/d81bf4581903b0cba0698cd4d1c07fc6be21754a

Original 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/