All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Maíra Canal" <mcanal@igalia.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 13/14] drm/v3d: Reject invalid out_sync handles in submit ioctls
Date: Thu, 04 Jun 2026 02:59:22 +0000	[thread overview]
Message-ID: <20260604025922.7A59B1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260603-v3d-sched-misc-fixes-v3-13-d7114bba55a0@igalia.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Resource leak (memory and drm_syncobj references) when parsing chained user-space extensions.
--

commit 42106e7ee90a922dbfb05df35206e0f77fc80751
Author: Maíra Canal <mcanal@igalia.com>

drm/v3d: Move out_sync syncobj lookup to submission

The commit moves the out_sync sync object lookup to the submission phase,
failing with -ENOENT if userspace passes a non-zero handle that doesn't
refer to a valid syncobj. It also consolidates the cleanup routines on
error paths for both single-sync and multi-sync implementations.

> diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
> index 2beb99a25104..dc27770d85fd 100644
> --- a/drivers/gpu/drm/v3d/v3d_submit.c
> +++ b/drivers/gpu/drm/v3d/v3d_submit.c
[ ... ]
> @@ -1032,6 +1034,12 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
>  		}
>  	}
>  

[Severity: High]
This isn't a bug introduced by this patch, but can the direct returns when
parsing extensions cause a resource leak?

In v3d_submit_cl_ioctl(), if userspace provides a valid
DRM_V3D_EXT_ID_MULTI_SYNC extension followed by an invalid one (e.g., an
unknown ID), v3d_get_extensions() will successfully allocate se.out_syncs
and acquire drm_syncobj references for the first extension, but then fail
on the second extension and return an error code.

Because the code directly returns here instead of jumping to a cleanup label,
it bypasses v3d_submit_put_post_deps(), leaking both the memory and the
drm_syncobj references.

Could this be triggered repeatedly by userspace chaining a valid multi-sync
extension with an invalid one, potentially exhausting kernel memory and file
descriptors?

> +	if (args->out_sync && !(se.flags & DRM_V3D_EXT_ID_MULTI_SYNC)) {
> +		sync_out = drm_syncobj_find(file_priv, args->out_sync);
> +		if (!sync_out)
> +			return -ENOENT;
> +	}
> +
>  	if (args->bcl_start != args->bcl_end) {
>  		bin = (struct v3d_bin_job *) v3d_submit_add_job(&submit, V3D_BIN);
>  		if (IS_ERR(bin)) {
[ ... ]
> @@ -1137,6 +1146,12 @@ v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
>  		}
>  	}
>  

[Severity: High]
This is a pre-existing issue, but the same resource leak when
v3d_get_extensions() fails appears here in v3d_submit_tfu_ioctl() as well.

> +	if (args->out_sync && !(se.flags & DRM_V3D_EXT_ID_MULTI_SYNC)) {
> +		sync_out = drm_syncobj_find(file_priv, args->out_sync);
> +		if (!sync_out)
> +			return -ENOENT;
> +	}
> +
>  	job = (struct v3d_tfu_job *) v3d_submit_add_job(&submit, V3D_TFU);
>  	if (IS_ERR(job)) {
>  		ret = PTR_ERR(job);
[ ... ]
> @@ -1234,6 +1250,12 @@ v3d_submit_csd_ioctl(struct drm_device *dev, void *data,
>  		}
>  	}
>  

[Severity: High]
This is a pre-existing issue, but the same resource leak when
v3d_get_extensions() fails also appears here in v3d_submit_csd_ioctl().

> +	if (args->out_sync && !(se.flags & DRM_V3D_EXT_ID_MULTI_SYNC)) {
> +		sync_out = drm_syncobj_find(file_priv, args->out_sync);
> +		if (!sync_out)
> +			return -ENOENT;
> +	}
> +
>  	ret = v3d_setup_csd_jobs_and_bos(&submit, args, &se);
>  	if (ret)
>  		goto fail;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603-v3d-sched-misc-fixes-v3-0-d7114bba55a0@igalia.com?part=13

  reply	other threads:[~2026-06-04  2:59 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-03 22:25 [PATCH v3 00/14] drm/v3d: Scheduler and submission fixes and refactoring Maíra Canal
2026-06-03 22:25 ` [PATCH v3 01/14] drm/v3d: Drop unused drm_encoder.h include from v3d_drv.h Maíra Canal
2026-06-03 22:25 ` [PATCH v3 02/14] drm/v3d: Clear queue->active_job when v3d_fence_create() fails Maíra Canal
2026-06-04  2:50   ` sashiko-bot
2026-06-03 22:25 ` [PATCH v3 03/14] drm/v3d: Use inline lock for dma fence initialization Maíra Canal
2026-06-04  2:49   ` sashiko-bot
2026-06-03 22:25 ` [PATCH v3 04/14] drm/v3d: Replace spin_lock_irqsave() with spin_lock() Maíra Canal
2026-06-04  2:51   ` sashiko-bot
2026-06-03 22:25 ` [PATCH v3 05/14] drm/v3d: Extract v3d_job_add_syncobjs() helper Maíra Canal
2026-06-03 22:25 ` [PATCH v3 06/14] drm/v3d: Reject invalid syncobj handles in submit ioctls Maíra Canal
2026-06-04  2:51   ` sashiko-bot
2026-06-03 22:25 ` [PATCH v3 07/14] drm/v3d: Migrate BO reservation locking to DRM exec Maíra Canal
2026-06-03 22:25 ` [PATCH v3 08/14] drm/v3d: Introduce struct v3d_submit and convert CL/TFU/CSD ioctls Maíra Canal
2026-06-04  2:54   ` sashiko-bot
2026-06-04  8:58   ` Tvrtko Ursulin
2026-06-04 11:52     ` Maíra Canal
2026-06-04 12:05       ` Tvrtko Ursulin
2026-06-04 12:10         ` Maíra Canal
2026-06-03 22:25 ` [PATCH v3 09/14] drm/v3d: Make v3d_get_cpu_indirect_csd_params() a pure parser Maíra Canal
2026-06-04  2:53   ` sashiko-bot
2026-06-03 22:25 ` [PATCH v3 10/14] drm/v3d: Convert submit helpers to operate on struct v3d_submit Maíra Canal
2026-06-04  9:49   ` Tvrtko Ursulin
2026-06-03 22:25 ` [PATCH v3 11/14] drm/v3d: Refactor CPU ioctl into unified submission chain Maíra Canal
2026-06-04  2:58   ` sashiko-bot
2026-06-04  9:54   ` Tvrtko Ursulin
2026-06-03 22:25 ` [PATCH v3 12/14] drm/v3d: Split BO fence attach from syncobj output handling Maíra Canal
2026-06-04  9:59   ` Tvrtko Ursulin
2026-06-03 22:25 ` [PATCH v3 13/14] drm/v3d: Reject invalid out_sync handles in submit ioctls Maíra Canal
2026-06-04  2:59   ` sashiko-bot [this message]
2026-06-04 10:12   ` Tvrtko Ursulin
2026-06-03 22:25 ` [PATCH v3 14/14] drm/v3d: Ensure atomic submissions in v3d_submit_jobs() Maíra Canal
2026-06-04 10:25   ` Tvrtko Ursulin

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=20260604025922.7A59B1F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mcanal@igalia.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.