DEBIAN-CVE-2024-39486

In the Linux kernel, the following vulnerability has been resolved: drm/drmfile: Fix pid refcounting race maarten.lankhorst@linux.intel.com, Maxime Ripard mripard@kernel.org, Thomas Zimmermann tzimmermann@suse.de filp->pid is supposed to be a refcounted pointer; however, before this patch, drmfileupdatepid() only increments the refcount of a struct pid after storing a pointer to it in filp->pid and dropping the dev->filelistmutex, making the following race possible: process A process B ========= ========= begin drmfileupdatepid mutexlock(&dev->filelistmutex) rcureplacepointer(filp->pid, <pid B>, 1) mutexunlock(&dev->filelistmutex) begin drmfileupdatepid mutexlock(&dev->filelistmutex) rcureplacepointer(filp->pid, <pid A>, 1) mutexunlock(&dev->filelistmutex) getpid(<pid A>) synchronizercu() putpid(<pid B>) * pid B reaches refcount 0 and is freed here get_pid(<pid B>) UAF * synchronizercu() putpid(<pid A>) As far as I know, this race can only occur with CONFIGPREEMPTRCU=y because it requires RCU to detect a quiescent state in code that is not explicitly calling into the scheduler. This race leads to use-after-free of a "struct pid". It is probably somewhat hard to hit because process A has to pass through a synchronizercu() operation while process B is between mutexunlock() and getpid(). Fix it by ensuring that by the time a pointer to the current task's pid is stored in the file, an extra reference to the pid has been taken. This fix also removes the condition for synchronizercu(); I think that optimization is unnecessary complexity, since in that case we would usually have bailed out on the lockless check above.