All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Baineng Shou" <shoubaineng@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] dma-buf: dma-heap: close installed fd when copy_to_user() fails
Date: Fri, 03 Jul 2026 08:17:54 +0000	[thread overview]
Message-ID: <20260703081755.5ACE11F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260703080922.1838362-1-shoubaineng@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Calling close_fd() on an installed file descriptor creates a race condition that can inadvertently close an unrelated file descriptor belonging to the process.
--

commit 61669c0c051aa2c310121591ca8897cc10b33840
Author: Baineng Shou <shoubaineng@gmail.com>

dma-buf: dma-heap: close installed fd when copy_to_user() fails

This patch attempts to fix a file descriptor leak when copy_to_user()
fails after allocating a DMA heap buffer. It tries to clean up the
leaked file descriptor by calling close_fd() if the copy to userspace
is unsuccessful.

> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index a76bf3f8b071a..0dd7a84b06bf4 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
[ ... ]
> @@ -181,8 +182,16 @@ static long dma_heap_ioctl(struct file *file, unsigned int ucmd,
>  		goto err;
>  	}
>  
> -	if (copy_to_user((void __user *)arg, kdata, out_size) != 0)
> +	if (copy_to_user((void __user *)arg, kdata, out_size) != 0) {
> +		if (kcmd == DMA_HEAP_IOCTL_ALLOC && ret == 0) {
> +			struct dma_heap_allocation_data *h = (void *)kdata;
> +
> +			close_fd(h->fd);

[Severity: High]
Does calling close_fd() on an installed file descriptor create a race
condition here in dma_heap_ioctl()?

By the time the execution reaches this error path, the file descriptor
has already been published to the process's file descriptor table via
fd_install() inside dma_heap_ioctl_allocate(). This means userspace
can already access it.

A concurrent thread could close the newly allocated file descriptor and
open a new file, reusing the same file descriptor number before the
copy_to_user() completes and fails.

If that happens, wouldn't this close_fd() inadvertently close an unrelated
file descriptor belonging to the process?

> +			h->fd = -1;
> +		}
>  		ret = -EFAULT;
> +	}
> +
>  err:
>  	if (kdata != stack_kdata)
>  		kfree(kdata);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703080922.1838362-1-shoubaineng@gmail.com?part=1

  reply	other threads:[~2026-07-03  8:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03  8:09 [PATCH] dma-buf: dma-heap: close installed fd when copy_to_user() fails Baineng Shou
2026-07-03  8:17 ` sashiko-bot [this message]
2026-07-03  8:26 ` Christian König
2026-07-10 10:57 ` [PATCH v2] dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds Baineng Shou
2026-07-10 11:06   ` sashiko-bot
2026-07-10 20:20     ` T.J. Mercier
2026-07-11  4:18       ` 寿柏能
2026-07-13 23:33         ` T.J. Mercier
2026-07-14 11:46           ` [PATCH v3 0/2] dma-buf: fix fd leak when copy_to_user() fails after fd_install() Baineng Shou
2026-07-14 11:46             ` [PATCH v3 1/2] dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds Baineng Shou
2026-07-14 13:13               ` David Laight
2026-07-14 13:38                 ` 寿柏能
2026-07-14 14:33                   ` David Laight
2026-07-14 11:46             ` [PATCH v3 2/2] misc: fastrpc: " Baineng Shou
2026-07-14 12:08               ` sashiko-bot
2026-07-14 12:24             ` [PATCH v3 0/2] dma-buf: fix fd leak when copy_to_user() fails after fd_install() Christian König
2026-07-14 13:27               ` [PATCH v3] drm/prime: use dma_buf_fd_install() to preserve export tracing Baineng Shou
2026-07-14 13:45                 ` sashiko-bot
2026-07-10 12:33   ` [PATCH v2] dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds Christian König
2026-07-11  4:14 ` Baineng Shou
2026-07-11  4:29   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260703081755.5ACE11F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=shoubaineng@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.