linux-kernel - Re: race between vfs_rename and do

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]

Date:   Tue, 15 Feb 2022 16:06:06 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Miklos Szeredi <miklos@...redi.hu>
Cc:     Xavier Roche <xavier.roche@...olia.com>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: race between vfs_rename and do_linkat (mv and link)

On Tue, Feb 15, 2022 at 01:37:40PM +0000, Al Viro wrote:
> On Tue, Feb 15, 2022 at 10:56:29AM +0100, Miklos Szeredi wrote:
> 
> > Doing "lock_rename() + lookup last components" would fix this race.
> 
> No go - thanks to the possibility of AT_SYMLINK_FOLLOW there.
> Think of it - we'd need to
> 	* lock parents (both at the same time)
> 	* look up the last component of source
> 	* if it turns a symlink - unlock parents and repeat the entire
> thing for its body, except when asked not to.
> 	* when we are done with the source, look the last component of
> target up
> 
> ... and then there is sodding -ESTALE handling, with all the elegance
> that brings in.
> 
> > If this was only done on retry, then that would prevent possible
> > performance regressions, at the cost of extra complexity.
> 
> Extra compared to the above, that is.  How delightful...

Actually, it's even viler than that: lock_rename() relies upon the
directories being locked sitting on the same fs.  Now, surely link(2)
would fail if source and target are on the different filesystem,
wouldn't it?  Alas, with AT_SYMLINK_FOLLOW it's quite possible to have
the source resolving to a symlink that does lead to the same fs as the
target, while the symlink itself is on a different fs.  So it's not
even straight lock_rename() - it has to be a special version that would
handle cross-fs invocations (somehow - e.g. ordering them on superblock
or mount in-core address in such case; ordering between dentries could
be arbitrary for cross-fs cases).

Worse, you need to deal with the corner cases.  "/" or anything ending on
"." or ".." can be rejected (no links to directories) and thankfully we
do not allow AT_EMPTY for linkat(2), but...  procfs symlinks are in the
game, since AT_SYMLINK_FOLLOW is there.

And _that_ is a real bitch - what "parent" would you lock for (followed)
/proc/self/fd/0?  It can change right under you; one solution would
be to grab ->vfs_rename_mutex first, same parent or not, then do what
lock_rename() does, relying upon ->d_parent having been stabilized
by ->vfs_rename_mutex.  But that would have to be conditional upon
running into that case - you don't want to serialize the shit out of
(same-directory) link(2) on given filesystem.  Which makes the entire
thing even harder to follow and reason about.

And to make it even more fun, you'll need to either duplicate pick_link()
guts, or try and make it usable in this situation.  Might or might not
be easy - I hadn't tried to go into that.

"Fucking ugly" is inadequate for the likely results of that approach.
It's guaranteed to be a source of headache for pretty much ever after.

Does POSIX actually make any promises in that area?  That would affect
how high a cost we ought to pay for that - I agree that it would be nicer
to have atomicity from userland point of view, but there's a difference
between hard bug and QoI issue.

Again, what really makes it painful is AT_SYMLINK_FOLLOW support in
linkat(2).  For plain link(2) it would be easier to deal with.