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: <5a4513fe-6eae-9269-c235-c8b0bc1ae05b@ispras.ru>
Date: Fri, 29 Aug 2025 10:21:35 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: linux-fsdevel@...r.kernel.org
cc: Alexander Viro <viro@...iv.linux.org.uk>, 
    Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, 
    linux-kernel@...r.kernel.org
Subject: Re: ETXTBSY window in __fput

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?

Alexander