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
| ||
|
Date: Tue, 19 Apr 2022 23:27:33 +0200 From: Max Kellermann <mk@...all.com> To: David Howells <dhowells@...hat.com> Cc: Max Kellermann <mk@...all.com>, linux-cachefs@...hat.com, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: fscache corruption in Linux 5.17? On 2022/04/19 18:42, David Howells <dhowells@...hat.com> wrote: > Could the file have been modified by a third party? If you're using NFS3 > there's a problem if two clients can modify a file at the same time. The > second write can mask the first write and the client has no way to detect it. > The problem is inherent to the protocol design. The NFS2 and NFS3 protocols > don't support anything better than {ctime,mtime,filesize} - the change > attribute only becomes available with NFS4. I tried to write a script to stress-test writing and reading, but found no clue so far. I'll continue that tomorrow. My latest theory is that this is a race condition; what if one process writes to the file, which invalidates the cache; then, in the middle of invalidating the local cache and sending the write to the NFS server, another process (on the same server) reads the file; what modification time and what data will it see? What if the cache gets filled with old data, while new data to-be-written is still in flight? Max
Powered by blists - more mailing lists