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.

• CWE-416

• https://git.kernel.org/stable/c/33927f3d0ecdcff06326d6e4edb6166aed42811cPatch
• https://git.kernel.org/stable/c/40deceb38f9db759772d1c289c28fd2a543f57fcPatch
• https://git.kernel.org/stable/c/55c232d7e0241f1d5120b595e7a9de24c75ed3d8Patch
• https://git.kernel.org/stable/c/c07886761fd6251db6938d4e747002e3d150d231Patch

Published

Sep 4, 2025

Last Modified

Jun 17, 2026

Status

Analyzed