CVE-2024-39486

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

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

Configurations

Configuration 1 (hide)

OR	cpe:2.3:o:linux:linux_kernel::::::::
	cpe:2.3:o:linux:linux_kernel::::::::
	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:6.10:rc3::::::
	cpe:2.3:o:linux:linux_kernel:6.10:rc4::::::
	cpe:2.3:o:linux:linux_kernel:6.10:rc5::::::

History

21 Nov 2024, 09:27

Type	Values Removed	Values Added
References	~~() https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844 - Patch~~	() https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844 - Patch
References	~~() https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa - Patch~~	() https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa - Patch
References	~~() https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9 - Patch~~	() https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9 - Patch

22 Aug 2024, 13:48

Type	Values Removed	Values Added
References	~~() https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844 -~~	() https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844 - Patch
References	~~() https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa -~~	() https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa - Patch
References	~~() https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9 -~~	() https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9 - Patch
CVSS	v2 : ~~unknown~~ v3 : ~~unknown~~	v2 : unknown v3 : 7.0
First Time		Linux linux Kernel Linux
CWE		CWE-416
CPE		cpe:2.3:o:linux:linux_kernel:6.10:rc1:::::: cpe:2.3:o:linux:linux_kernel:6.10:rc3:::::: cpe:2.3:o:linux:linux_kernel:6.10:rc5:::::: cpe:2.3:o:linux:linux_kernel:::::::: cpe:2.3:o:linux:linux_kernel:6.10:rc2:::::: cpe:2.3:o:linux:linux_kernel:6.10:rc4::::::

15 Jul 2024, 07:15

Type	Values Removed	Values Added
Summary	(en) 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, <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) 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.
Summary	(es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/drm_file: corrige la carrera 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 carrera: 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 carrera 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 ejecucón conduce al 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.	(es) 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.

08 Jul 2024, 15:49

Type	Values Removed	Values Added
Summary		(es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/drm_file: corrige la carrera 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 carrera: 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 carrera 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 ejecucón conduce al 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.

06 Jul 2024, 10:15

Type	Values Removed	Values Added
New CVE

7.0^/10

Attack Vector LOCAL

Attack Complexity HIGH

Privileges Required LOW

User Interaction NONE

Confidentiality Impact HIGH

Integrity Impact HIGH

Availability Impact HIGH

Scope UNCHANGED