All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Thadeu Lima de Souza Cascardo" <cascardo@igalia.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/atomic: remove bogus check for file_priv
Date: Mon, 17 Aug 2026 18:57:53 +0000	[thread overview]
Message-ID: <20260817185754.0E7191F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260817-drm_atomic_bogus_check-v2-1-2b9e60f32a7e@igalia.com>

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

Pre-existing issues:
- [High] A memory leak of `struct drm_pending_vblank_event` occurs in `prepare_signaling` when an error happens during out-fence setup and `DRM_MODE_PAGE_FLIP_EVENT` is not requested, allowing userspace to exhaust kernel memory.
--

--- Patch [1]: [PATCH v2] drm/atomic: remove bogus check for file_priv ---
commit 51977ecd1b08bc9f3e31da1b4219cb831a4fdaa9
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>

drm/atomic: remove bogus check for file_priv

This commit removes an unreachable check for file_priv being NULL at
prepare_signaling() since it can never be NULL. If it were NULL, skipping
the block would cause the drm_pending_vblank_event object to leak. Since
it is unreachable, no leak was possible from this specific check.

Link: https://patch.msgid.link/20260729-drm_atomic_bogus_check-v1-1-a4d5bd4ae4c8@igalia.com

> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index e997917819e8e..657c15474ed50 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1445,9 +1445,6 @@ static int prepare_signaling(struct drm_device *dev,
>  		if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
>  			struct drm_pending_vblank_event *e = crtc_state->event;
>  
> -			if (!file_priv)
> -				continue;
> -
>  			ret = drm_event_reserve_init(dev, file_priv, &e->base,
>  						     &e->event.base);
>  			if (ret) {

[Severity: High]
This is a pre-existing issue, but does prepare_signaling() leak the
drm_pending_vblank_event object when an out-fence setup fails?

If userspace calls DRM_IOCTL_MODE_ATOMIC without the DRM_MODE_PAGE_FLIP_EVENT
flag, but with an OUT_FENCE_PTR property pointing to an invalid memory
address, prepare_signaling() allocates the event:

	e = create_vblank_event(crtc, arg->user_data);

Because DRM_MODE_PAGE_FLIP_EVENT is not set, drm_event_reserve_init() is
skipped, leaving e->base.file_priv as NULL.

Later, setup_out_fence() can fail during put_user() due to the invalid
pointer, returning -EFAULT:

	ret = setup_out_fence(&f[(*num_fences)++], fence);
	if (ret) {
		dma_fence_put(fence);
		return ret;
	}

This returns early before crtc_state->event->base.fence is set.

On the error unwinding path, complete_signaling() checks if it should free
the event:

	if (event && (event->base.fence || event->base.file_priv)) {
		drm_event_cancel_free(dev, &event->base);
		crtc_state->event = NULL;
	}

Since both base.fence and base.file_priv are NULL, it skips freeing the
event.

Can a malicious userspace program repeatedly trigger this failure to exhaust
kernel memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260817-drm_atomic_bogus_check-v2-1-2b9e60f32a7e@igalia.com?part=1

      reply	other threads:[~2026-08-17 18:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17 18:45 [PATCH v2] drm/atomic: remove bogus check for file_priv Thadeu Lima de Souza Cascardo
2026-08-17 18:57 ` sashiko-bot [this message]

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=20260817185754.0E7191F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=cascardo@igalia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --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.