CVE-2025-38722

In the Linux kernel, the following vulnerability has been resolved: habanalabs: fix UAF in export_dmabuf() As soon as we'd inserted a file reference into descriptor table, another thread could close it. That's fine for the case when all we are doing is returning that descriptor to userland (it's a race, but it's a userland race and there's nothing the kernel can do about it). However, if we follow fd_install() with any kind of access to objects that would be destroyed on close (be it the struct file itself or anything destroyed by its ->release()), we have a UAF. dma_buf_fd() is a combination of reserving a descriptor and fd_install(). habanalabs export_dmabuf() calls it and then proceeds to access the objects destroyed on close. In particular, it grabs an extra reference to another struct file that will be dropped as part of ->release() for ours; that "will be" is actually "might have already been". Fix that by reserving descriptor before anything else and do fd_install() only when everything had been set up. As a side benefit, we no longer have the failure exit with file already created, but reference to underlying file (as well as ->dmabuf_export_cnt, etc.) not grabbed yet; unlike dma_buf_fd(), fd_install() can't fail.
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:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*

History

30 Oct 2026, 13:18

Type Values Removed Values Added
References
  • () https://git.kernel.org/stable/c/5b0c23e9ec3e161a893d6ff9b4fad479e4539627 -

21 Oct 2026, 13:18

Type Values Removed Values Added
References
  • () https://git.kernel.org/stable/c/d26058c2349d77d1ef179a2cc9752ca12004b6ff -

19 Oct 2026, 21:10

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: habanalabs: corrige UAF en export_dmabuf() Tan pronto como hubiéramos insertado una referencia de archivo en la tabla de descriptores, otro hilo podría cerrarla. Eso está bien para el caso en que todo lo que estamos haciendo es devolver ese descriptor al espacio de usuario (es una condición de carrera, pero es una condición de carrera del espacio de usuario y no hay nada que el kernel pueda hacer al respecto). Sin embargo, si después de fd_install() seguimos con cualquier tipo de acceso a objetos que serían destruidos al cerrar (ya sea la propia struct file o cualquier cosa destruida por su ->release()), tenemos un UAF. dma_buf_fd() es una combinación de reservar un descriptor y fd_install(). habanalabs export_dmabuf() lo llama y luego procede a acceder a los objetos destruidos al cerrar. En particular, toma una referencia adicional a otra struct file que será liberada como parte de ->release() para la nuestra; ese 'será' es en realidad 'podría haber sido ya'. Corregir eso reservando el descriptor antes que nada y haciendo fd_install() solo cuando todo hubiera sido configurado. Como beneficio adicional, ya no tenemos la salida por fallo con el archivo ya creado, pero la referencia al archivo subyacente (así como ->dmabuf_export_cnt, etc.) aún no tomada; a diferencia de dma_buf_fd(), fd_install() no puede fallar.

Information

Published : 2025-09-04 16:15

Updated : 2026-10-30 13:18


NVD link : CVE-2025-38722

Mitre link : CVE-2025-38722

CVE.ORG link : CVE-2025-38722


JSON object : View

Products Affected

linux

  • linux_kernel
CWE
CWE-416

Use After Free