https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 03:52:33 +0000 https://db.gcve.eu/vuln/cve-2025-38722 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>habanalabs: fix UAF in export_dmabuf()</p> <p>As soon as we&#39;d inserted a file reference into descriptor table, another thread could close it. That&#39;s fine for the case when all we are doing is returning that descriptor to userland (it&#39;s a race, but it&#39;s a userland race and there&#39;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 -&gt;release()), we have a UAF.</p> <p>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 -&gt;release() for ours; that &#34;will be&#34; is actually &#34;might have already been&#34;.</p> <p>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 -&gt;dmabuf_export_cnt, etc.) not grabbed yet; unlike dma_buf_fd(), fd_install() can&#39;t fail.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>habanalabs: fix UAF in export_dmabuf()</p> <p>As soon as we&#39;d inserted a file reference into descriptor table, another thread could close it. That&#39;s fine for the case when all we are doing is returning that descriptor to userland (it&#39;s a race, but it&#39;s a userland race and there&#39;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 -&gt;release()), we have a UAF.</p> <p>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 -&gt;release() for ours; that &#34;will be&#34; is actually &#34;might have already been&#34;.</p> <p>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 -&gt;dmabuf_export_cnt, etc.) not grabbed yet; unlike dma_buf_fd(), fd_install() can&#39;t fail.</p> https://db.gcve.eu/vuln/cve-2025-38722