mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Pavel Skripkin <paskripkin@gmail.com>,
	sumit.semwal@linaro.org, gustavo@padovan.org,
	christian.koenig@amd.com, daniel.vetter@ffwll.ch
Cc: linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org,
	syzbot+5c943fe38e86d615cac2@syzkaller.appspotmail.com
Subject: Re: [Linaro-mm-sig] [PATCH next] dma-buf/sync-file: do not allow zero size allocations
Date: Wed, 30 Mar 2022 09:09:14 +0200	[thread overview]
Message-ID: <8af3d213-6cb7-a021-c198-e1bd37c47e7c@gmail.com> (raw)
In-Reply-To: <20220329221425.22691-1-paskripkin@gmail.com>

That problem is already fixed with patch 21d139d73f77 dma-buf/sync-file: 
fix logic error in new fence merge code.

Am 30.03.22 um 00:14 schrieb Pavel Skripkin:
> syzbot reported GPF in dma_fence_array_first(), which is caused by
> dereferencing ZERO_PTR in dma-buf internals.
>
> ZERO_PTR was generated in sync_file_merge(). This functuion tries to
> reduce allocation size, but does not check if it reducing to 0.

This is actually perfectly ok. The code above should have prevented the 
size to become 0.

Regards,
Christian.

>
> Fix reported bug by validating `index` value before passing it to
> krealloc_array().
>
> Fail log:
>
> general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
> CPU: 1 PID: 3595 Comm: syz-executor814 Not tainted 5.17.0-next-20220328-syzkaller #0
> ...
> RIP: 0010:dma_fence_array_first+0x78/0xb0 drivers/dma-buf/dma-fence-array.c:234
> ...
> Call Trace:
>   <TASK>
>   __dma_fence_unwrap_array include/linux/dma-fence-unwrap.h:42 [inline]
>   dma_fence_unwrap_first include/linux/dma-fence-unwrap.h:57 [inline]
>   sync_file_ioctl_fence_info drivers/dma-buf/sync_file.c:414 [inline]
>   sync_file_ioctl+0x248/0x22c0 drivers/dma-buf/sync_file.c:477
>   vfs_ioctl fs/ioctl.c:51 [inline]
>   __do_sys_ioctl fs/ioctl.c:870 [inline]
>
> There was same problem with initial kcalloc() allocation in same
> function, so it's fixed as well.
>
> Reported-and-tested-by: syzbot+5c943fe38e86d615cac2@syzkaller.appspotmail.com
> Fixes: 519f490db07e ("dma-buf/sync-file: fix warning about fence containers")
> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
> ---
>   drivers/dma-buf/sync_file.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index b8dea4ec123b..aa744f017008 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -212,7 +212,7 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a,
>   	dma_fence_unwrap_for_each(b_fence, &b_iter, b->fence)
>   		++num_fences;
>   
> -	if (num_fences > INT_MAX)
> +	if (num_fences > INT_MAX || !num_fences)
>   		goto err_free_sync_file;
>   
>   	fences = kcalloc(num_fences, sizeof(*fences), GFP_KERNEL);
> @@ -264,7 +264,7 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a,
>   	if (index == 0)
>   		add_fence(fences, &index, dma_fence_get_stub());
>   
> -	if (num_fences > index) {
> +	if (index && num_fences > index) {
>   		struct dma_fence **tmp;
>   
>   		/* Keep going even when reducing the size failed */


  reply	other threads:[~2022-03-30  7:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29 22:14 Pavel Skripkin
2022-03-30  7:09 ` Christian König [this message]
2022-03-30 18:24   ` [Linaro-mm-sig] " Pavel Skripkin
2022-03-31  6:23     ` Christian König
2022-04-01 21:31       ` [PATCH next v2] dma-buf/sync-file: do not allow zero size allocation Pavel Skripkin
2022-04-03 15:05         ` Christian König

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=8af3d213-6cb7-a021-c198-e1bd37c47e7c@gmail.com \
    --to=ckoenig.leichtzumerken@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo@padovan.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=paskripkin@gmail.com \
    --cc=sumit.semwal@linaro.org \
    --cc=syzbot+5c943fe38e86d615cac2@syzkaller.appspotmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome