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: <e7110cd2-289a-127e-a8c1-f191e346d38d@ispras.ru>
Date: Fri, 29 Aug 2025 13:17:16 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: Christian Brauner <brauner@...nel.org>
cc: 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


On Fri, 29 Aug 2025, Christian Brauner wrote:

> On Fri, Aug 29, 2025 at 10:21:35AM +0300, Alexander Monakov wrote:
> > 
> > On Wed, 27 Aug 2025, Alexander Monakov wrote:
> > 
> > > Dear fs hackers,
> > > 
> > > I suspect there's an unfortunate race window in __fput where file locks are
> > > dropped (locks_remove_file) prior to decreasing writer refcount
> > > (put_file_access). If I'm not mistaken, this window is observable and it
> > > breaks a solution to ETXTBSY problem on exec'ing a just-written file, explained
> > > in more detail below.
> > 
> > The race in __fput is a problem irrespective of how the testcase triggers it,
> > right? It's just showing a real-world scenario. But the issue can be
> > demonstrated without a multithreaded fork: imagine one process placing an
> > exclusive lock on a file and writing to it, another process waiting on that
> > lock and immediately execve'ing when the lock is released.
> > 
> > Can put_file_access be moved prior to locks_remove_file in __fput?
> 
> 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?
And maybe other things too. So why not fix the ordering issue in __fput
and if there are other bugs breaking valid uses of flock, fix them too?

Alexander