Re: [PATCH v5 4/4] drm: Add per-signal compare functionality to drm_user_fence

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Blocking workqueue threads indefinitely via get_user() and userfaultfd/FUSE.
--

commit ca21d7e20dc2d16871f1fee93d9a731a24dbe2fa
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
drm: Add per-signal compare functionality to drm_user_fence

This commit adds optional compare fields to drm_user_fence and a helper
function to configure them. When configured, the worker reads a value from
userspace via get_user() upon fence signaling, and executes the callback
only if the comparison passes.

> diff --git a/drivers/gpu/drm/drm_user_fence.c b/drivers/gpu/drm/drm_user_fence.c
> index 664178e2d74cf..9e141533622e7 100644
> --- a/drivers/gpu/drm/drm_user_fence.c
> +++ b/drivers/gpu/drm/drm_user_fence.c
[ ... ]
> @@ -12,21 +12,68 @@
[ ... ]
>  static void drm_user_fence_do_work(struct drm_work_fence *wfence)
>  {
[ ... ]
> +	if (ufence->cmp_op != DRM_USER_FENCE_CMP_NONE) {
> +		if (!mm_ok) {
> +			call_worker = false;
> +		} else {
> +			u64 cur_val;
> +
> +			if (get_user(cur_val, ufence->cmp_addr) ||

[Severity: High]
Can a malicious userspace application configure cmp_addr to point to a memory
region monitored by userfaultfd or a slow FUSE filesystem, and intentionally
never resolve the page fault?

Since drm_user_fence_do_work() runs on a kernel workqueue thread, blocking
indefinitely in get_user() without pagefault protections could stall the
workqueue. If this workqueue is shared, ordered, or thread-pool constrained,
this could prevent other kernel tasks from executing and lead to a denial of
service.

> +			    !drm_user_fence_cmp_match(cur_val,
> +						      ufence->cmp_value,
> +						      ufence->cmp_op))
> +				call_worker = false;
> +		}
> +	}
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827062142.4038272-1-srinivasan.shanmugam@amd.com?part=4