linux-kernel - Re: [PATCH 5.15] fuse: Fix race condition in writethrough path A race

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: <CAJfpeguoN5m4QVnwHPfyoq7=_BMRkWTBWZmY8iy7jMgF_h3uhA@mail.gmail.com>
Date: Tue, 14 Oct 2025 09:48:34 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Brian Foster <bfoster@...hat.com>
Cc: lu gu <giveme.gulu@...il.com>, Joanne Koong <joannelkoong@...il.com>, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Bernd Schubert <bernd@...ernd.com>
Subject: Re: [PATCH 5.15] fuse: Fix race condition in writethrough path A race

On Mon, 13 Oct 2025 at 20:49, Brian Foster <bfoster@...hat.com> wrote:

> Hrm Ok. But even if we did miss remote changes, whose to say we can even
> resolve that correctly from the kernel anyways..?

No, I'm worrying about the case of

- range1 cached locally,
- range1 changed remotely (mtime changed)
- range2 changed locally (mtime changed, cached mtime invalidated)
- range1 read locally

That last one will update mtime in cache, see that old cached mtime is
stale and happily read the stale data.

What we currently have is more correct in the sense that it will
invalidate data on any mtime change, be it of local or remote origin.

> > Yes, reproducer has auto_inval_data turned on (libfuse turns it on by default).
> >
>
> I was more wondering if the problem goes away if it were disabled..

I haven't tried, @guangming?

> Ah, yeah that makes sense. Though invalidate waits on writeback. Any
> reason this path couldn't skip the dirty state but mark the pages as
> under writeback across the op?

Maybe that'd work.  It *is* under writeback after all.

Maybe the solution is to change the write-through to regular cached
write + fsync range?  That could even be a complexity reduction.

Thanks,
Miklos