From: <gregkh@linuxfoundation.org>
To: torvalds@linux-foundation.org, dvyukov@google.com,
ebiggers3@gmail.com, gregkh@linuxfoundation.org,
vegard.nossum@gmail.com, viro@zeniv.linux.org.uk
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "vfs: don't do RCU lookup of empty pathnames" has been added to the 3.18-stable tree
Date: Wed, 21 Feb 2018 10:39:54 +0100 [thread overview]
Message-ID: <1519205994232179@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
vfs: don't do RCU lookup of empty pathnames
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
vfs-don-t-do-rcu-lookup-of-empty-pathnames.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From c0eb027e5aef70b71e5a38ee3e264dc0b497f343 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun, 2 Apr 2017 17:10:08 -0700
Subject: vfs: don't do RCU lookup of empty pathnames
From: Linus Torvalds <torvalds@linux-foundation.org>
commit c0eb027e5aef70b71e5a38ee3e264dc0b497f343 upstream.
Normal pathname lookup doesn't allow empty pathnames, but using
AT_EMPTY_PATH (with name_to_handle_at() or fstatat(), for example) you
can trigger an empty pathname lookup.
And not only is the RCU lookup in that case entirely unnecessary
(because we'll obviously immediately finalize the end result), it is
actively wrong.
Why? An empth path is a special case that will return the original
'dirfd' dentry - and that dentry may not actually be RCU-free'd,
resulting in a potential use-after-free if we were to initialize the
path lazily under the RCU read lock and depend on complete_walk()
finalizing the dentry.
Found by syzkaller and KASAN.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: Vegard Nossum <vegard.nossum@gmail.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/namei.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1851,6 +1851,9 @@ static int path_init(int dfd, const char
{
int retval = 0;
+ if (!*s)
+ flags &= ~LOOKUP_RCU;
+
nd->last_type = LAST_ROOT; /* if there are only slashes... */
nd->flags = flags | LOOKUP_JUMPED;
nd->depth = 0;
Patches currently in stable-queue which might be from torvalds@linux-foundation.org are
queue-3.18/vfs-don-t-do-rcu-lookup-of-empty-pathnames.patch
next reply other threads:[~2018-02-21 9:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-21 9:39 gregkh [this message]
2018-02-21 9:43 ` Patch "vfs: don't do RCU lookup of empty pathnames" has been added to the 3.18-stable tree Greg KH
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=1519205994232179@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=dvyukov@google.com \
--cc=ebiggers3@gmail.com \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vegard.nossum@gmail.com \
--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).