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