From: Alice Ryhl <aliceryhl@google.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: phasta@mailbox.org, boris.brezillon@collabora.com,
gary@garyguo.net, lossin@kernel.org,
daniel.almeida@collabora.com, joelagnelf@nvidia.com,
sumit.semwal@linaro.org, dri-devel@lists.freedesktop.org,
linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH] dma-buf/dma_fence: be more defensive in dma_fence_release
Date: Wed, 18 Mar 2026 12:25:36 +0000 [thread overview]
Message-ID: <abqZwCJhPFeu7hAy@google.com> (raw)
In-Reply-To: <20260317144825.2318-1-christian.koenig@amd.com>
On Tue, Mar 17, 2026 at 03:48:25PM +0100, Christian König wrote:
> In case of a refcounting bug dma_fence_release() can be called before the
> fence was even signaled.
>
> Previously the dma_fence framework then force signaled the fence to make
> sure to unblock waiters, but that can potentially lead to random memory
> corruption when the DMA operation continues. So be more defensive here and
> pick the lesser evil.
>
> Instead of force signaling the fence set an error code on the fence,
> re-initialize the refcount to something large and taint the kernel.
>
> This will leak memory and eventually can cause a deadlock when the fence
> is never signaled, but at least we won't run into an use after free or
> random memory corruption.
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
> drivers/dma-buf/dma-fence.c | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 1826ba73094c..8bf07685a053 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -593,14 +593,24 @@ void dma_fence_release(struct kref *kref)
> /*
> * Failed to signal before release, likely a refcounting issue.
> *
> - * This should never happen, but if it does make sure that we
> - * don't leave chains dangling. We set the error flag first
> - * so that the callbacks know this signal is due to an error.
> + * This should never happen, but if try to be defensive and take
> + * the lesser evil. Initialize the refcount to something large,
> + * but not so large that it can overflow.
> + *
> + * That will leak memory and could deadlock if the fence never
> + * signals, but at least it doesn't cause an use after free or
> + * random memory corruption.
> + *
> + * Also taint the kernel to note that it is rather unreliable to
> + * continue.
> */
> dma_fence_lock_irqsave(fence, flags);
> fence->error = -EDEADLK;
> - dma_fence_signal_locked(fence);
> + refcount_set(&fence->refcount.refcount, INT_MAX);
It's much better to leave the refcount with a value of zero here. That
way, when the refcount is decremented next time, the usual underflow
detection checks will trigger.
You can still skip the kfree() to avoid use-after-free.
Alice
prev parent reply other threads:[~2026-03-18 12:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 14:48 [PATCH] dma-buf/dma_fence: be more defensive in dma_fence_release Christian König
2026-03-17 15:21 ` Boris Brezillon
2026-03-18 8:21 ` Christian König
2026-03-18 9:18 ` Boris Brezillon
2026-03-18 9:50 ` Christian König
2026-03-18 12:25 ` Alice Ryhl [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abqZwCJhPFeu7hAy@google.com \
--to=aliceryhl@google.com \
--cc=boris.brezillon@collabora.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=joelagnelf@nvidia.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-media@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=phasta@mailbox.org \
--cc=sumit.semwal@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.