linux-kernel - [BUG] 9p: data corruption with cache=mmap under concurrent stat/write

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-next>] [day] [month] [year] [list]

Message-Id: <aea6cd1d-ff2b-4288-8196-edfdfd1539f6@app.fastmail.com>
Date: Wed, 24 Dec 2025 15:29:01 +0100
From: "Pierre Barre" <pierre@...re.sh>
To: ericvh@...nel.org, lucho@...kov.net, asmadeus@...ewreck.org
Cc: linux_oss@...debyte.com, v9fs@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: [BUG] 9p: data corruption with cache=mmap under concurrent stat/write

Hi,

I'm hitting data corruption using 9p with cache=mmap when stat() is called concurrently with writes.

Environment:
- Kernel: v6.18.1-061801
- Mount options: cache=mmap
- Transport: unix

Reproducer:
1. Mount 9p filesystem with cache=mmap
2. Run PostgreSQL with data directory on 9p mount
3. Run pgbench workload
4. Simultaneously run `watch -n 0.1 tree -ah` on the data directory

PostgreSQL reports:
  ERROR: unexpected data beyond EOF in block N of relation "..."
  HINT: This has been seen to occur with buggy kernels

Analysis:

The issue appears to be race conditions in getattr/setattr when using
writeback caching:

1. v9fs_vfs_getattr_dotl() condition checks `v9ses->cache` instead of
   `v9ses->cache & CACHE_WRITEBACK`, triggering writeback flush for
   any cache mode
2. Both getattr and setattr call filemap_fdatawrite() which initiates
   writeback but doesn't wait for completion. The subsequent server
   stat/wstat sees stale file size.

Would using filemap_write_and_wait() instead be the correct fix?

Thanks,
Pierre Barre