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 <[email protected]> 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/[email protected]?part=1
