On Wed, 2026-09-09 at 15:14 +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. > > Signed-off-by: Christian König <[email protected]> > Fixes: 035219a760ed ("dma-buf: dma-fence: Fix potential NULL pointer > dereference") > CC: [email protected] # 7.2+ > Reported-by: Jonghyuk Kim(MalHyuk) <[email protected]> > Tested-by: Jonghyuk Kim(MalHyuk) <[email protected]> > --- > drivers/dma-buf/dma-fence.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 05090fb0fd5a..e92f9df8d63c 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 (ops) > + if (!dma_fence_test_signaled_flag(fence) && ops)
It's probably a good idea to comment at an appropriate place (I suggest here and at dma_fence_ops) why this is necessary, because at all other places the ops-pointer can serve as decoupling point. Reason is simply to also support drivers that implement release() and wait(), preventing ops from being set to NULL. P.
