Race Condition Affecting kernel-devel package, versions *
Threat Intelligence
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk ID SNYK-RHEL7-KERNELDEVEL-7433642
- published 10 Jul 2024
- disclosed 6 Jul 2024
Introduced: 6 Jul 2024
CVE-2024-39486 Open this link in a new tabHow to fix?
There is no fixed version for RHEL:7 kernel-devel.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-devel package and not the kernel-devel package as distributed by RHEL.
See How to fix? for RHEL:7 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
drm/drm_file: 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, 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, <pid B>, 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, <pid A>, 1) mutex_unlock(&dev->filelist_mutex) get_pid(<pid A>) synchronize_rcu() put_pid(<pid B>) *** pid B reaches refcount 0 and is freed here *** get_pid(<pid B>) *** UAF *** synchronize_rcu() put_pid(<pid A>)
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.