Re: [PATCH] fix: dma-buf: unwrap_merge_complex: dma_fence_get_stub reference leaked on all paths

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Double free / refcount underflow on the global static `dma_fence_stub` in `unwrap_merge_complex()`.
--

commit 361d06ca0291c480e1aafadac1b89e324d9431ab
Author: WenTao Liang <vulab@iscas.ac.cn>

fix: dma-buf: unwrap_merge_complex: dma_fence_get_stub reference leaked on all paths

This commit fixes a reference leak on the global stub fence in
unwrap_merge_complex() by adding dma_fence_put() calls to the success and
error paths.

> diff --git a/drivers/dma-buf/st-dma-fence-unwrap.c b/drivers/dma-buf/st-dma-fence-unwrap.c
> --- a/drivers/dma-buf/st-dma-fence-unwrap.c
> +++ b/drivers/dma-buf/st-dma-fence-unwrap.c
[ ... ]
> @@ -530,8 +531,10 @@ static int unwrap_merge_complex(void *arg)
>  		err = -EINVAL;
>  	}
>  
> +	dma_fence_put(stub);
>  	dma_fence_put(f5);
> -error_put_f4:
> +error_put_stub:
> +	dma_fence_put(stub);

[Severity: Medium]
Does this cause a double-put of the stub on the success path?

When unwrap_merge_complex() successfully completes, it appears execution
will call dma_fence_put(stub) just before putting f5, and then fall right
through into the error_put_stub label where it calls dma_fence_put(stub) a
second time.

Since dma_fence_get_stub() only acquires a single reference, putting it
twice would underflow the refcount and trigger dma_fence_release(). This
could result in an attempt to call kfree_rcu() on the statically allocated
dma_fence_stub global variable, causing a panic during the selftest.

Would it be better to only place dma_fence_put(stub) after the
error_put_stub label, allowing the success path to fall through and clean
it up once naturally along with the other fences?

>  	dma_fence_put(f4);
>  error_put_f3:
>  	dma_fence_put(f3);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260626122836.35856-1-vulab@iscas.ac.cn?part=1