From: Nick Piggin <npiggin@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nick Piggin <npiggin@kernel.dk>,
linux-fsdevel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [patch] fs: fix d_validate
Date: Wed, 17 Nov 2010 14:49:57 +1100 [thread overview]
Message-ID: <20101117034957.GA3302@amd> (raw)
In-Reply-To: <AANLkTin_am+PNEc0xWKurpb4XRFSf0CwFN4hSQMTNb+L@mail.gmail.com>
On Tue, Nov 16, 2010 at 08:20:52AM -0800, Linus Torvalds wrote:
> On Mon, Nov 15, 2010 at 10:23 PM, Nick Piggin <npiggin@kernel.dk> wrote:
> >
> > fs: d_validate fixes
> >
> > d_validate has been broken for a long time.
> >
> > kmem_ptr_validate does not guarantee that a pointer can be dereferenced
> > if it can go away at any time. Even rcu_read_lock doesn't help, because
> > the pointer might be queued in RCU callbacks but not executed yet.
>
> Hmm. Iirc (and it's possible that I don't) the original reason for the
> whole kmem_ptr_validate() was for nfsd sending dentry pointers back
> and forth as part of the FH.
Yeah that looked to be the case, when I checked old kernels.
> So we really _did_ need to do basic validation, and no, we didn't care
> about things like DEBUG_PAGEALLOC, because that's totally
> inappropriate for a nfs server anyway. So it was "broken", but it
> worked.
>
> Now, I hope that kind of "we really fundamentally cannot even trust
> the pointer" doesn't exist any more, in which case I agree with you.
> But historically, it really did matter at some point, and when the
> code says "insecure source", it really means it - it could
> historically have come from user space or over the network.
Well there is nothing in the tree that uses it after my patch to
fix d_validate (that was the only user). d_validate itself was only
used for a funny dir cache in ncpfs and smbfs which has a cache of
pointers to dentries but no references on them, which is pretty hard
to sanely do anything with.
I imagine that if such a kind of cache turns out to be needed in any
relevant filesystem, it could be properly implemented in the dcache
code and not have to play those games. If any user really comes up
for an untrusted pointer, we can always resurrect this -- the kmem
API is not broken as such, but it's just really easy to use wrongly.
prev parent reply other threads:[~2010-11-17 3:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-16 6:23 [patch] fs: fix d_validate Nick Piggin
2010-11-16 6:24 ` [patch] kernel: get rid of *_ptr_validate Nick Piggin
2010-11-16 10:21 ` Christoph Hellwig
2010-11-16 10:20 ` [patch] fs: fix d_validate Christoph Hellwig
2010-11-16 10:25 ` Nick Piggin
2010-11-16 16:28 ` Christoph Hellwig
2010-11-17 3:51 ` Nick Piggin
2010-11-16 16:20 ` Linus Torvalds
2010-11-16 16:25 ` Christoph Hellwig
2010-11-17 3:49 ` Nick Piggin [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=20101117034957.GA3302@amd \
--to=npiggin@kernel.dk \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).