Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [Critical] Pre-existing Use-After-Free in dma_buf_fd() via concurrent close() after fd installation. -- --- Patch [1]: [PATCH v2] dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds --- commit a57039a5644f218873e246c9fb9fe2f87ef4dc55 Author: Baineng Shou <[email protected]> dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. Link: https://lore.kernel.org/dri-devel/[email protected]/ > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 71f37544a5c61..c2f455d028b30 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -799,6 +799,26 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags) > } > EXPORT_SYMBOL_NS_GPL(dma_buf_fd, "DMA_BUF"); [Severity: Critical] This is a pre-existing issue, but does dma_buf_fd() have a use-after-free if the file descriptor is closed concurrently? Looking at dma_buf_fd() just above this diff: fd = FD_ADD(flags, dmabuf->file); DMA_BUF_TRACE(trace_dma_buf_fd, dmabuf, fd); Once FD_ADD() installs the fd, it becomes visible to userspace. If a concurrent thread guesses the fd and calls close(fd), the file's reference count drops to zero, triggering fput() and eventually freeing the dmabuf structure. When the original thread continues to DMA_BUF_TRACE(), won't it dereference the now-freed dmabuf pointer? [ ... ] -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
