CVE-2024-39486
drm/drm_file: Fix pid refcounting race
Severity Score
Exploit Likelihood
Affected Versions
Public Exploits
0Exploited in Wild
-Decision
Descriptions
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.
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/drm_file: corrige la ejecución de recuento de pid filp->pid se supone que es un puntero recontado; sin embargo, antes de este parche, drm_file_update_pid() solo incrementa el recuento de una estructura pid después de almacenar un puntero a ella en filp->pid y eliminar dev->filelist_mutex, haciendo posible la siguiente ejecución: proceso A proceso B ==== ===== ========= comenzar 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 alcanza refcount 0 y se libera aquí *** get_pid() *** UAF *** synchronize_rcu() put_pid() Hasta donde yo sé, esta ejecución solo puede ocurrir con CONFIG_PREEMPT_RCU=y porque requiere que RCU detecte un estado inactivo en el código que no llame explícitamente al programador. Esta ejecución conduce a use after free de una "estructura pid". Probablemente sea algo difícil de lograr porque el proceso A tiene que pasar por una operación synchronize_rcu() mientras que el proceso B está entre mutex_unlock() y get_pid(). Solucionelo asegurándose de que cuando se almacene en el archivo un puntero al pid de la tarea actual, se haya tomado una referencia adicional al pid. Esta solución también elimina la condición de synchronize_rcu(); Creo que la optimización es una complejidad innecesaria, ya que en ese caso normalmente habríamos abandonado la verificación sin bloqueo anterior.
A race condition was found in the Linux kernel. The rm_file_update_pid() only increments the refcount of a struct pid after storing a pointer to it in filp->pid, dropping the dev->filelist_mutex, resulting in a use-after-free vulnerability.
Linux DRM has drm_file_update_pid() call to get_pid() too late, which creates a race condition that can lead to use-after-free issue of a struct pid.
CVSS Scores
SSVC
- Decision:Track
Timeline
- 2024-06-25 CVE Reserved
- 2024-07-06 CVE Published
- 2024-08-23 EPSS Updated
- 2024-12-19 CVE Updated
- ---------- Exploited in Wild
- ---------- KEV Due Date
- ---------- First Exploit
CWE
- CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
CAPEC
References (7)
| URL | Tag | Source |
|---|---|---|
| https://git.kernel.org/stable/c/031ddd28008971cce0b5626379b910d0a05fb4dd | Vuln. Introduced | |
| https://git.kernel.org/stable/c/1c7a387ffef894b1ab3942f0482dac7a6e0a909c | Vuln. Introduced |
| URL | Date | SRC |
|---|
| URL | Date | SRC |
|---|---|---|
| https://access.redhat.com/security/cve/CVE-2024-39486 | 2024-11-12 | |
| https://bugzilla.redhat.com/show_bug.cgi?id=2296383 | 2024-11-12 |
Affected Vendors, Products, and Versions
| Vendor | Product | Version | Other | Status | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Vendor | Product | Version | Other | Status | <-- --> | Vendor | Product | Version | Other | Status |
| Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 6.6.9 < 6.6.37 Search vendor "Linux" for product "Linux Kernel" and version " >= 6.6.9 < 6.6.37" | en |
Affected
| ||||||
| Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 6.7 < 6.9.8 Search vendor "Linux" for product "Linux Kernel" and version " >= 6.7 < 6.9.8" | en |
Affected
| ||||||
| Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 6.7 < 6.10 Search vendor "Linux" for product "Linux Kernel" and version " >= 6.7 < 6.10" | en |
Affected
| ||||||