linux-kernel - Re: [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: <2332946.iZASKD2KPV@weasel>
Date: Wed, 17 Dec 2025 14:41:31 +0100
From: Christian Schoenebeck <linux_oss@...debyte.com>
To: Eric Van Hensbergen <ericvh@...nel.org>,
 Latchesar Ionkov <lucho@...kov.net>, asmadeus@...ewreck.org,
 Chris Arges <carges@...udflare.com>,
 Dominique Martinet <asmadeus@...ewreck.org>
Cc: v9fs@...ts.linux.dev, linux-kernel@...r.kernel.org,
 David Howells <dhowells@...hat.com>, Matthew Wilcox <willy@...radead.org>,
 linux-fsdevel@...r.kernel.org
Subject:
 Re: [PATCH] 9p/virtio: restrict page pinning to user_backed_iter() iovec

On Tuesday, 9 December 2025 22:04:23 CET Dominique Martinet via B4 Relay 
wrote:
> From: Dominique Martinet <asmadeus@...ewreck.org>
> 
> When doing a loop mount of a filesystem over 9p, read requests can come
> from unexpected places and blow up as reported by Chris Arges with this
> reproducer:
> ```
> dd if=/dev/zero of=./xfs.img bs=1M count=300
> yes | mkfs.xfs -b size=8192 ./xfs.img
> rm -rf ./mount && mkdir -p ./mount
> mount -o loop ./xfs.img ./mount
> ```
> 
> The problem is that iov_iter_get_pages_alloc2() apparently cannot be
> called on folios (as illustrated by the backtrace below), so limit what
> iov we can pin from !iov_iter_is_kvec() to user_backed_iter()
[...] 
> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> index
> 10c2dd48643818907f4370243eb971fceba4d40b..f7ee1f864b03a59568510eb0dd3496bd0
> 5b3b8d6 100644 --- a/net/9p/trans_virtio.c
> +++ b/net/9p/trans_virtio.c
> @@ -318,7 +318,7 @@ static int p9_get_mapped_pages(struct virtio_chan *chan,
> if (!iov_iter_count(data))
>  		return 0;
> 
> -	if (!iov_iter_is_kvec(data)) {
> +	if (user_backed_iter(data)) {
>  		int n;
>  		/*
>  		 * We allow only p9_max_pages pinned. We wait for the
> 
> ---
> base-commit: 3e281113f871d7f9c69ca55a4d806a72180b7e8a
> change-id: 20251210-virtio_trans_iter-5973892db2e3

Something's seriously messed up with 9p cache right now. With today's git 
master I do get data corruption in any 9p cache mode, including cache=mmap, 
only cache=none behaves clean.

With this patch applied though it gets even worse as I can't even boot due to 
immediate 9p data corruption. Could be coincidence, as I get corruption 
without this patch in any cache mode as well, but at least I have to try much 
harder to trigger it.

Currently busy with other stuff, so could be a while before being able to 
identify the cause.

/Christian