Re: [PATCH v2] drm/atomic: remove bogus check for file_priv

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 <[email protected]>

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/[email protected]

> 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/[email protected]?part=1