From: Al Viro <viro@ZenIV.linux.org.uk>
To: Sasha Levin <sasha.levin@oracle.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
bfields@redhat.com, mszeredi@suse.cz,
"Eric W. Biederman" <ebiederm@xmission.com>,
hch@lst.de, Dave Jones <davej@redhat.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: dcache: NULL ptr deref in dentry_kill
Date: Mon, 6 Oct 2014 06:35:23 +0100 [thread overview]
Message-ID: <20141006053523.GD7996@ZenIV.linux.org.uk> (raw)
In-Reply-To: <54321CF4.9070101@oracle.com>
On Mon, Oct 06, 2014 at 12:39:16AM -0400, Sasha Levin wrote:
> if (!IS_ROOT(dentry)) {
> parent = dentry->d_parent;
> if (unlikely(!spin_trylock(&parent->d_lock))) { <=== here
> if (inode)
> spin_unlock(&inode->i_lock);
> goto failed;
>
> We're trying to deref a NULL 'parent'.
->d_parent is *never* NULL. There are very few places where it's modified,
all of them in fs/dcache.c:
fs/dcache.c:1416: dentry->d_parent = dentry;
fs/dcache.c:1453: dentry->d_parent = parent;
fs/dcache.c:2478: dentry->d_parent = target->d_parent;
fs/dcache.c:2479: target->d_parent = target;
fs/dcache.c:2484: swap(dentry->d_parent, target->d_parent);
The fifth one exchanges two something->d_parent. Can't introduce NULL.
Neither can the third one (again, foo->d_parent = bar->d_parent). The
first and the fourth are also obvious - p->d_parent = p will oops with
p == NULL and store a non-NULL otherwise. Which leaves the second -
d_alloc(). And there the lines immediately after that assignment are
list_add(&dentry->d_u.d_child, &parent->d_subdirs);
spin_unlock(&parent->d_lock);
which would oops with parent == NULL.
Dentries are allocated by __d_alloc(). By the time somebody might
observe them, they already have non-NULL ->d_parent. And they never
get it set to NULL afterwards. I don't see any variables (auto or not)
of type struct dentry and I don't see anything that would contain
struct dentry as a field. It doesn't guarantee that nobody manages
to allocate one somehow or hide a conversion of some strange pointer to
struct dentry *, but any such place would be very likely to trigger tons
of oopsen - it would have to manage to hide initialization of ->d_subdirs,
->d_lru, ->d_alias, etc. and it's hard to do accidentally.
Another possibility is that this pointer either never went to struct dentry
or used to point to one in times long past, and memory had been zeroed
since then. Or that something has shat some zeroes into a real struct
dentry, corrupting ->d_parent in process.
But any struct dentry with NULL ->d_parent is a serious bug. That really
should never, ever happen.
prev parent reply other threads:[~2014-10-06 5:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-06 0:27 dcache: NULL ptr deref in dentry_kill Sasha Levin
2014-10-06 3:13 ` Al Viro
2014-10-06 3:42 ` Sasha Levin
2014-10-06 4:25 ` Al Viro
2014-10-06 4:39 ` Sasha Levin
2014-10-06 5:35 ` Al Viro [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=20141006053523.GD7996@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=bfields@redhat.com \
--cc=davej@redhat.com \
--cc=ebiederm@xmission.com \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mszeredi@suse.cz \
--cc=sasha.levin@oracle.com \
/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).