linux-kernel - Re: [PATCH 1/2] vfs: Do not allow mnt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120530020134.GA20448@ZenIV.linux.org.uk>
Date:	Wed, 30 May 2012 03:01:34 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Luk?? Czerner <lczerner@...hat.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	mbroz@...hat.com
Subject: Re: [PATCH 1/2] vfs: Do not allow mnt_longterm to go negative

On Tue, May 29, 2012 at 12:56:44PM +0200, Luk?? Czerner wrote:
> 
> Anyone can take a look at this ? It's pretty pressing I would say
> since this bug will not only disallow to unattach the loop devices
> but also make it unable to actually unmount the file system!

I agree that it's a bug, but I don't believe that this is a proper
fix.  We can do it much simpler.  Look: making these guys longterm
happens exactly at the same points where we set their ->mnt_ns non-NULL.
Remember that "longterm" == "internal kernel mount, mount in some
namespace, someone's root or pwd".  So the problem is that umount_tree()
is that umount_tree() blindly assumes that it's killing a longterm
ref, even though it may be called when dissolving a tree that never
made it into anyone's namespace.  Fine, so let's just have that
sucker do
                if (p->mnt_ns)
                        __mnt_make_shortterm(p);
                p->mnt_ns = NULL;
instead and that's all it takes.  Alternatively, we can just turn the
code in mntput_no_expire() into
	if (likely(mnt->mnt_ns || atomic_read(...))
and get rid of longterm/shortterm logics around ->mnt_ns completely.
Short-term, pardon the bad pun, I'm going with the first variant; it's
less intrusive.  Longer term I think we want to get rid of playing with
mnt_longterm in there and just check ->mnt_ns as well when deciding to
go for the fast path in mntput_no_expire().

Fixed in my tree, will push in a couple of hours.  And that'll need to
go into -stable as well.  Thanks for catching that sucker...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/