All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Helge Deller <deller@gmx.de>
Cc: Helge Deller <deller@kernel.org>,
	linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>
Subject: Re: [RFC] [PATCH] Fix warning at fs/dcache.c:430 dentry_free
Date: Mon, 6 Apr 2026 21:38:01 +0100	[thread overview]
Message-ID: <20260406203801.GB3836593@ZenIV> (raw)
In-Reply-To: <cfd3b7e4-b791-41b3-9f9b-76082025a906@gmx.de>

On Mon, Apr 06, 2026 at 10:21:17PM +0200, Helge Deller wrote:
> Hi Al,
> 
> On 4/6/26 22:07, Al Viro wrote:
> > On Mon, Apr 06, 2026 at 09:52:16PM +0200, Helge Deller wrote:
> > > The debian buildd servers for the parisc architecture crash reproduceably when
> > > building the webkit2gtk debian package, shortly after having shown the warning
> > > below.
> > > 
> > > This patch keeps the lock of the dentry up until when the dentry is given back
> > > to the cache and after having freed the "external dentry name".
> > > 
> > > I'm not sure if this patch is really correct, but it seems to have fixed the
> > > problem, although more testing is needed.
> > 
> > Hard NAK.  You are turning every place that grabs ->d_lock on a dentry scheduled
> > for freeing (like, say it, any RCU pathwalk trying to check if the end result can
> > be grabbed) into a UAF.
> 
> Thanks for looking into the patch!
> I assume UAF means User-after-free?
> As I'm not an expert here, could you please point me to where
> this use-after-free happens?
> The kfree() is used on the external dentry name, and the lock is
> unlocked before calling kmem_cache_free(), so I'd not expect that I
> introduced an UAF here. But of course I could be wrong....

s/UAF/deadlock/, actually.

A:	rcu_read_lock();
A:	find a dentry (lockless)
B:	grab dentry->d_lock
B:	dentry_free(dentry);
B:		call_rcu(..., __d_free) (or __d_free_external - whatever)
A:	grab dentry->d_lock, so we could verify that it's still live

A spins until __d_free() unlocks the sucker, which is not going to be called
until A does rcu_read_unlock().

  reply	other threads:[~2026-04-06 20:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-06 19:52 [RFC] [PATCH] Fix warning at fs/dcache.c:430 dentry_free Helge Deller
2026-04-06 20:07 ` Al Viro
2026-04-06 20:21   ` Helge Deller
2026-04-06 20:38     ` Al Viro [this message]
2026-04-06 20:28   ` Al Viro
2026-04-06 20:43     ` Helge Deller
2026-04-06 21:10       ` Al Viro
2026-04-07 16:24         ` Helge Deller

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=20260406203801.GB3836593@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=brauner@kernel.org \
    --cc=deller@gmx.de \
    --cc=deller@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.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.