CVE-2024-39486 Information

Description

In the Linux kernel the following vulnerability has been resolved:

drm/drm_file: Fix pid refcounting race

filp->pid is supposed to be a refcounted pointer; however before this patch drm_file_update_pid() only increments the refcount of a struct pid after storing a pointer to it in filp->pid and dropping the dev->filelist_mutex making the following race possible:

process A process B ========= ========= begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid 1) mutex_unlock(&dev->filelist_mutex) get_pid() synchronize_rcu() put_pid() pid B reaches refcount 0 and is freed here get_pid() UAF synchronize_rcu() put_pid()

As far as I know this race can only occur with CONFIG_PREEMPT_RCU=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 synchronize_rcu() operation while process B is between mutex_unlock() and get_pid().

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 synchronize_rcu(); I think that optimization is unnecessary complexity since in that case we would usually have bailed out on the lockless check above.

Reference

https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844 https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9