Re: [PATCH] dma-buf/test: add KUnit case for dma_fence_dedup_array() empty input

[sashiko-bot@kernel.org]

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

New issues:
- [Medium] The newly added test_dedup_empty KUnit test will unconditionally fail, breaking CI.

Pre-existing issues:
- [Critical] dma_fence_dedup_array() incorrectly returns 1 for an empty array, causing uninitialized memory dereference in amdgpu_userq_wait_return_fence_info().
--

commit 693b63d34624f1aa69f2c97819d4a6d6655ec6bc
Author: Baineng Shou <shoubaineng@gmail.com>

dma-buf/test: add KUnit case for dma_fence_dedup_array() empty input

This commit adds a KUnit test case to verify that dma_fence_dedup_array()
returns 0 when provided with an empty array. The test aims to ensure the
documented contract is enforced and prevents future regressions.

> diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c b/drivers/dma-buf/st-dma-fence-unwrap.c
> index 4e7ee25372ba6..72dea6091d583 100644
> --- a/drivers/dma-buf/st-dma-fence-unwrap.c
> +++ b/drivers/dma-buf/st-dma-fence-unwrap.c

[ ... ]

> @@ -370,6 +370,15 @@ static void test_unwrap_merge_seqno(struct kunit *test)
>  	dma_fence_put(f1);
>  }
>  
> +static void test_dedup_empty(struct kunit *test)
> +{
> +	struct dma_fence *fence[1] = { NULL };
> +	int ret;
> +
> +	ret = dma_fence_dedup_array(fence, 0);
> +	KUNIT_EXPECT_EQ(test, ret, 0);

[Severity: Medium]
Will this test fail unconditionally on the current tree?

Looking at dma_fence_dedup_array() in drivers/dma-buf/dma-fence-unwrap.c,
there is no early return for an empty array:

int dma_fence_dedup_array(struct dma_fence **fences, int num_fences)
{
        int i, j;

        sort(fences, num_fences, sizeof(*fences), fence_cmp, NULL);

        j = 0;
        for (i = 1; i < num_fences; i++) {
                ...
        }

        return ++j;
}

The loop condition i < num_fences is skipped when num_fences is 0, but the
function ends with return ++j, which returns 1. Since this patch adds a
KUnit expectation for 0, won't this cause CI to break until the corresponding
fix for dma_fence_dedup_array() is actually applied to the tree?

[Severity: Critical]
This is a pre-existing issue, but does dma_fence_dedup_array() returning 1
for empty arrays cause an uninitialized memory dereference in other
subsystems?

For example, in drivers/gpu/drm/amd/amdgpu/amdgpu_userq_fence.c:
amdgpu_userq_wait_return_fence_info() uses kmalloc_array for the fences array
and eventually calls dma_fence_dedup_array:

        num_fences = dma_fence_dedup_array(fences, num_fences);

        waitq = amdgpu_userq_get(userq_mgr, wait_info->waitq_id);
        if (!waitq) {
        ...
        for (i = 0, cnt = 0; i < num_fences; i++) {
                struct amdgpu_userq_fence_driver *fence_drv;
                struct amdgpu_userq_fence *userq_fence;
                u32 index;

                userq_fence = to_amdgpu_userq_fence(fences[i]);

If an unprivileged user triggers a path via ioctl where 0 fences are populated
but dma_fence_dedup_array() is called with num_fences = 0, returning 1 will
cause the subsequent loop to iterate once. Will this dereference an
uninitialized garbage pointer from kmalloc_array() when to_amdgpu_userq_fence()
evaluates fences[i]?

> +}
> +
>  static void test_unwrap_merge_order(struct kunit *test)

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630060436.1527498-1-shoubaineng@gmail.com?part=1