Re: [PATCH v2] dma-buf: dma-fence: Fix potential NULL pointer dereference

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Replacing the signaled-bit check with an `ops` null-check causes driver callbacks to be executed on signaled fences, violating the dma-fence contract and leading to a Use-After-Free.
--

commit f3771b2534b5990287b2b373aaf5a26b9dea2923
Author: Philipp Stanner <phasta@kernel.org>

dma-buf: dma-fence: Fix potential NULL pointer dereference

The patch removes the signaled-bit check in dma_fence_timeline_name() and
dma_fence_driver_name(), replacing it with a check for a non-NULL ops pointer
to prevent potential out-of-order execution issues.

> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index c7ea1e75d38a2..0a025dfdf131e 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -1170,7 +1170,7 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence)
>  
>  	/* RCU protection is required for safe access to returned string */
>  	ops = rcu_dereference(fence->ops);
> -	if (!dma_fence_test_signaled_flag(fence))
> +	if (ops)

[Severity: High]
Does this expose a use-after-free for signaled fences?

If a fence has a .release or .wait callback,
dma_fence_signal_timestamp_locked() does not set fence->ops to NULL. For
those fences, ops will remain non-NULL indefinitely even after they are
signaled.

By removing the signaled-bit check, won't ops->get_driver_name(fence) be
called on signaled fences? The dma-fence contract states that backing data
can be freed after an RCU grace period once the fence is signaled, so calling
this callback could access freed memory.

>  		return (const char __rcu *)ops->get_driver_name(fence);
>  	else
>  		return (const char __rcu *)"detached-driver";
> @@ -1203,7 +1203,7 @@ const char __rcu *dma_fence_timeline_name(struct dma_fence *fence)
>  
>  	/* RCU protection is required for safe access to returned string */
>  	ops = rcu_dereference(fence->ops);
> -	if (!dma_fence_test_signaled_flag(fence))
> +	if (ops)

[Severity: High]
Could this lead to the same use-after-free as above?

Since ops can remain non-NULL for signaled fences that provide a .release
or .wait callback, this allows the ops callback to be executed after the
fence is signaled and its backing data is potentially freed.

>  		return (const char __rcu *)ops->get_driver_name(fence);
>  	else
>  		return (const char __rcu *)"signaled-timeline";

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629075636.2513214-2-phasta@kernel.org?part=1