CVE-2025-38722

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