Re: [PATCH 1/2] dma-buf/dma-fence: fix checking signaling bit for timeline and driver name v2

[Philipp Stanner <phasta@mailbox.org>]

On Mon, 2026-09-14 at 20:27 +0200, Christian König wrote:
> The patch "dma-buf: dma-fence: Fix potential NULL pointer dereference"
> changed the check to test for the ops pointer instead of the signaled
> bit to avoid a potential NULL dereference when the ops pointer has been
> cleared.
> 
> The problem is now that the ops pointer is cleared only when neither the
> release nor the wait callback is implemented and this isn't true for a lot
> of dma_fence implementations yet. So those implementations lost the RCU
> protection after signaling of the returned string resulting in potential
> use after free.
> 
> Add the signaling check additional to the ops pointer check so that we
> have both the protection against NULL dereference as well as the RCU
> protection after signaling for the returned string.
> 
> v2: improve comments to note RCU protection and explain why we check
>     both signaling state and ops pointer
> 
> Signed-off-by: Christian König <christian.koenig@amd.com>
> Fixes: 035219a760ed ("dma-buf: dma-fence: Fix potential NULL pointer dereference")
> CC: stable@vger.kernel.org # 7.2+
> Reported-by: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com>
> Tested-by: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com>

Reviewed-by: Philipp Stanner <phasta@kernel.org>

> ---
>  drivers/dma-buf/dma-fence.c | 16 ++++++++++++++--
>  include/linux/dma-fence.h   |  6 ++++++
>  2 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 05090fb0fd5ae..f52675f3ba03a 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -1170,7 +1170,13 @@ 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 (ops)
> +
> +	/*
> +	 * Check both signaled state and ops pointer, we don't know which one is
> +	 * loaded first and ops pointer is only set to NULL on newer
> +	 * implementations.
> +	 */

nit: "we don't know" doesn't give the reader confidence that the
ordering is right. I would more say "Load ordering is irrelevant
because …".


P.