linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Sami Liedes <sami.liedes@iki.fi>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: Intentionally corrupted vfat fs causing BUG
Date: Sun, 19 Oct 2014 18:36:10 +0200	[thread overview]
Message-ID: <5443E87A.2060207@nod.at> (raw)
In-Reply-To: <87r3yc5oqt.fsf@devron.myhome.or.jp>

Am 13.10.2014 um 10:59 schrieb OGAWA Hirofumi:
> Richard Weinberger <richard@nod.at> writes:
> 
>> Am 13.10.2014 um 10:35 schrieb OGAWA Hirofumi:
>>> Richard Weinberger <richard@nod.at> writes:
>>>
>>>>> I'm still not sure whether this is right direction or not though,
>>>>> because mount operation is root only and untrusted image should run fsck
>>>>> before. But, also, Oops is clearly unexpected. Hmmm...
>>>>
>>>> This limitation is not true anymore. Plug in a USB stick into a recent
>>>> Linux desktop, it will automatically mount it...  Also think of user
>>>> namespaces and FUSE.
>>>
>>> Not really (well, true, some sort though). It is still controlled by root
>>> or capability, right?  I.e. still controlled by admin of system.
>>
>> Fact is, I can plugin a USB stick to my buddies Laptop and make it trigger a BUG_ON. :)
>>
>>> I read user namespaces last time, it doesn't allow to mount the block
>>> device by namespace's root.
>>>
>>> FUSE is allowed to mount by true user (I.e. admin can't disallow it)? I
>>> still didn't check it fully.
>>
>> The question is how long these limits will stay...
>> User namespaces uncovered already a pile of issues wrt. to mounting.
> 
> Well, anyway, I don't object like that simple patch.
> 
> My worry is, I feel we need something like online-fsck finally if we
> tackled fully to avoid issues (I still didn't analyze about this issue
> seriously and fully), and measurable overheads.
> 
> And I myself have interest to online/runtime-fsck (i.e. detect and fix)
> though, I don't have interest to make it generic operations, and I would
> not have interest to tackle for all FSes...
> 

What about this one?

diff --git a/fs/fat/namei_vfat.c b/fs/fat/namei_vfat.c
index 6df8d3d..60a28b7 100644
--- a/fs/fat/namei_vfat.c
+++ b/fs/fat/namei_vfat.c
@@ -736,7 +736,8 @@ static struct dentry *vfat_lookup(struct inode *dir, struct dentry *dentry,
 	}

 	alias = d_find_alias(inode);
-	if (alias && !vfat_d_anon_disconn(alias)) {
+	if (alias && !vfat_d_anon_disconn(alias) &&
+	    alias->d_parent == dentry->d_parent) {
 		/*
 		 * This inode has non anonymous-DCACHE_DISCONNECTED
 		 * dentry. This means, the user did ->lookup() by an

VFAT suffers from the issue because it is using dentry aliases to have fast lookups
for short and long names. Without aliases the VFS will catch the loop just fine as on ext2 (I've
tested it).
Let's change vfat_lookup() to verify that both the alias and dentry have the same parent otherwise
we're facing a loop.

Thanks,
//richard

  parent reply	other threads:[~2014-10-19 16:36 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-10 20:57 Intentionally corrupted vfat fs causing BUG Sami Liedes
2014-10-11 10:20 ` Richard Weinberger
2014-10-12 12:08 ` OGAWA Hirofumi
2014-10-12 19:04   ` Richard Weinberger
2014-10-12 20:40     ` Sami Liedes
2014-10-13  7:57     ` OGAWA Hirofumi
2014-10-13  8:22       ` Richard Weinberger
2014-10-13  8:35         ` OGAWA Hirofumi
2014-10-13  8:39           ` Richard Weinberger
2014-10-13  8:59             ` OGAWA Hirofumi
2014-10-13 14:36               ` Richard Weinberger
2014-10-19 16:36               ` Richard Weinberger [this message]
2014-10-23 15:28                 ` OGAWA Hirofumi
2014-10-23 16:01                   ` Al Viro
2014-10-23 16:16                     ` Al Viro
2014-10-23 16:45                       ` OGAWA Hirofumi
2014-10-23 16:50                         ` OGAWA Hirofumi
2014-10-23 16:55                           ` Richard Weinberger
2014-10-23 16:55                         ` Al Viro
2014-10-23 17:21                           ` Al Viro
2014-10-23 17:58                             ` OGAWA Hirofumi
2014-10-23 20:46                             ` Sami Liedes
2014-10-23 17:35                           ` OGAWA Hirofumi
2014-10-23 17:54                           ` J. Bruce Fields
2014-10-23 18:05                             ` Al Viro
2014-10-23 18:16                               ` J. Bruce Fields
2014-10-23 16:56                         ` Al Viro

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=5443E87A.2060207@nod.at \
    --to=richard@nod.at \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sami.liedes@iki.fi \
    --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).