linux-kernel - Re: ETXTBSY window in _

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: <fkq7gvtjqx4jilgu75nbmckmwdndl7d7fzljuycqfzmvumdft2@jiycade6gzgo>
Date: Fri, 29 Aug 2025 16:02:52 +0200
From: Jan Kara <jack@...e.cz>
To: Alexander Monakov <amonakov@...ras.ru>
Cc: Christian Brauner <brauner@...nel.org>, linux-fsdevel@...r.kernel.org, 
	Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: ETXTBSY window in __fput

Hello!

On Fri 29-08-25 14:45:57, Alexander Monakov wrote:
> On Fri, 29 Aug 2025, Christian Brauner wrote:
> 
> > > > Even if we fix this there's no guarantee that the kernel will give that
> > > > letting the close() of a writably opened file race against a concurrent
> > > > exec of the same file will not result in EBUSY in some arcane way
> > > > currently or in the future.
> > > 
> > > Forget Go and execve. Take the two-process scenario from my last email.
> > > The program waiting on flock shouldn't be able to observe elevated
> > > refcounts on the file after the lock is released. It matters not only
> > > for execve, but also for unmounting the underlying filesystem, right?
> > 
> > What? No. How?: with details, please.
> 
> Apologies if there's a misunderstanding on my side, but put_file_access
> does file_put_write_access, which in turn does
> 
>   mnt_put_write_access(file->f_path.mnt);
> 
> and I think elevated refcount on mnt will cause -EBUSY from mnt_hold_writers.
> Which is then checked in mnt_make_readonly. I expect it affects unmount too,
> just don't see exactly where.

Umount (may_umount_tree()) looks at mnt->mnt_count which is decremented by
mntput() completely at the end of __fput(). I tend to agree with Christian
here: We've never promised that all effects of open fd are cleaned up
before the flock is released and as Christian explained it will be actually
pretty hard to implement such behavior. So attempts to wait for fd to close
by waiting for its flock are racy...

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR