linux-kernel - Re: 9p read corruption of mmaped content (Was: [PATCH] 9p/virtio: restrict page pinning to user_backed

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: <aUU8thEsa0X4YrlF@codewreck.org>
Date: Fri, 19 Dec 2025 20:53:26 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: David Howells <dhowells@...hat.com>,
	Christian Schoenebeck <linux_oss@...debyte.com>
Cc: Eric Van Hensbergen <ericvh@...nel.org>,
	Latchesar Ionkov <lucho@...kov.net>,
	Chris Arges <carges@...udflare.com>, v9fs@...ts.linux.dev,
	linux-kernel@...r.kernel.org, Matthew Wilcox <willy@...radead.org>,
	linux-fsdevel@...r.kernel.org
Subject: Re: 9p read corruption of mmaped content (Was: [PATCH] 9p/virtio:
 restrict page pinning to user_backed_iter() iovec)

Dominique Martinet wrote on Fri, Dec 19, 2025 at 01:09:26PM +0900:
> - I took a dump of dmesg (with debug=65535) and tracepoints (netfs, 9p),
> and it looks like the mmaped file IO is mostly correct? -- a TREAD is
> issued with the correct size, I'm seeing the data is collected... and..
> what is that ZERO SUBMT with the same size? Could it be related?
> David, could you please have a look?

So answering myself on that ZERO submit now I've looked up the
tracepoint definition, s=%x is the start offset and the following item
is the length so [0-5fb2[ was "downloaded from the server" and
[5fb2-6000[ was "filled with zero", and there's nothing wrong here...

Both are triggered straight from the page fault so that answers my last
question as well:

clang     691 [000] 18146.476058: netfs:netfs_sreq: R=0003306d[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0
        ffffffff81601197 __traceiter_netfs_sreq+0x37 ([kernel.kallsyms])
        ffffffff8160625a netfs_read_subreq_terminated+0x10a ([kernel.kallsyms])
        ffffffff817fcbc6 v9fs_issue_read+0x86 ([kernel.kallsyms])
        ffffffff815fd86b netfs_read_to_pagecache+0x18b ([kernel.kallsyms])
        ffffffff815fdc62 netfs_readahead+0x152 ([kernel.kallsyms])
        ffffffff814b9c2a read_pages+0x4a ([kernel.kallsyms])
        ffffffff814b9f20 page_cache_ra_unbounded+0x190 ([kernel.kallsyms])
        ffffffff814ba677 page_cache_ra_order+0x387 ([kernel.kallsyms])
        ffffffff814ae2a9 filemap_fault+0x5c9 ([kernel.kallsyms])
        ffffffff814ee518 __do_fault+0x38 ([kernel.kallsyms])
        ffffffff814f83a5 __handle_mm_fault+0xbb5 ([kernel.kallsyms])
        ffffffff814f9509 handle_mm_fault+0x99 ([kernel.kallsyms])
        ffffffff812a6e2f do_user_addr_fault+0x1ef ([kernel.kallsyms])
        ffffffff81ceb097 exc_page_fault+0x67 ([kernel.kallsyms])
        ffffffff81000bb7 asm_exc_page_fault+0x27 ([kernel.kallsyms])
            7f776ed86c23 clang::SrcMgr::ContentCache::getInvalidBOM(llvm::StringRef)+0x13 (/usr/lib/x86_64-linux-gnu/li

Which leaves me absolutely clueless at where to look next, I assume the
data is populated cleanly but by the time later pages are read by clang
the content changed or something like that?
I'll try harder to create a synthetic/more deterministic reproducer for
now...

Any ideas welcome...!
-- 
Dominique Martinet | Asmadeus