Several drivers call dma_buf_fd() — which internally calls fd_install() — before copy_to_user() returns the fd number to userspace. If copy_to_user() fails, the fd is already published in the caller's fd table but the ioctl returns an error, so userspace never learns the fd number. Worse, the window between fd_install() and copy_to_user() allows other threads to observe and manipulate the fd (dup, close, SCM_RIGHTS), making any "close it on the failure path" fix unsafe.
The fix is to split the allocation into three steps: reserve an fd with get_unused_fd_flags() (not yet visible to other threads), do copy_to_user(), and only then publish the fd with fd_install() via the new dma_buf_fd_install() helper. On copy_to_user() failure, put_unused_fd() + dma_buf_put() cleanly unwind with no user-visible side effects. Patch 1 introduces dma_buf_fd_install() in dma-buf.c (wrapping fd_install() together with the DMA_BUF_TRACE call to preserve export tracing) and applies the fix to dma-heap. Patch 2 applies the same fix to fastrpc, which even had a comment acknowledging the problem could not be fixed before. v1: https://lore.kernel.org/dri-devel/[email protected]/ v2: https://lore.kernel.org/dri-devel/[email protected]/ Changes in v3: - Split into two patches (dma-heap + fastrpc separately) - Add dma_buf_fd_install() to preserve trace_dma_buf_fd tracepoint (spotted by T.J. Mercier and sashiko-bot on v2) - Add fastrpc fix using the new helper (suggested by T.J. Mercier) Baineng Shou (2): dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds misc: fastrpc: don't publish fd before copy_to_user() succeeds drivers/dma-buf/dma-buf.c | 20 ++++++++++ drivers/dma-buf/dma-heap.c | 80 +++++++++++++++++++------------------- drivers/misc/fastrpc.c | 16 +++----- include/linux/dma-buf.h | 1 + 4 files changed, 67 insertions(+), 50 deletions(-) -- 2.34.1
