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.
References
Configurations
Configuration 1 (hide)
|
History
22 Aug 2024, 13:48
| Type | Values Removed | Values Added |
|---|---|---|
| First Time |
Linux
Linux linux Kernel |
|
| CWE | CWE-416 | |
| CPE | cpe:2.3:o:linux:linux_kernel:6.10:rc5:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.10:rc4:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.10:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.10:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.10:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
|
| References | () https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa - Patch | |
| References | () https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844 - Patch | |
| References | () https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9 - Patch | |
| CVSS |
v2 : v3 : |
v2 : unknown
v3 : 7.0 |
15 Jul 2024, 07:15
| Type | Values Removed | Values Added |
|---|---|---|
| Summary | 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. |
06 Jul 2024, 10:15
| Type | Values Removed | Values Added |
|---|---|---|
| New CVE |
Information
Published : 2024-07-06 10:15
Updated : 2024-08-22 13:48
NVD link : CVE-2024-39486
Mitre link : CVE-2024-39486
JSON object : View
Products Affected
linux
- linux_kernel
CWE
CWE-416
Use After Free