linux-kernel - Re: kernel BUG when mounting large block xfs backed by 9p (folio ref count bug)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aTWF6xnCe1sSA8gQ@codewreck.org>
Date: Sun, 7 Dec 2025 22:49:31 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Chris Arges <carges@...udflare.com>
Cc: Christian Schoenebeck <linux_oss@...debyte.com>,
	Matthew Wilcox <willy@...radead.org>,
	David Howells <dhowells@...hat.com>, ericvh@...nel.org,
	lucho@...kov.net, v9fs@...ts.linux.dev,
	linux-kernel@...r.kernel.org, kernel-team@...udflare.com
Subject: Re: kernel BUG when mounting large block xfs backed by 9p (folio ref
 count bug)

Chris,

I'm not sure why but I can't reproduce with your .config either :/
If you can still reproduce this reliably, could you try with the
following diff applied (which is basically the same as what Christian
suggested a couple of days ago with also ubuf, whatever that is)
------------
diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index 10c2dd486438..f7ee1f864b03 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
-----------



Willy,

Matthew Wilcox wrote on Sun, Dec 07, 2025 at 07:18:02AM +0000:
> In readahead, we allocate a folio, lock it and add it to the page cache.
> We then submit it to the filesystem for read.  It cannot be truncated
> from the page cache until the filesystem unlocks it (generally by calling
> folio_end_read() but some filesystems explicitly call folio_unlock()
> instead).  So you don't need to take an extra reference to it.

Thanks.

My main problem with this all is that trans_virtio adds the buffers to
the virtio virtqueue but does nothing to take it off if
wait_event_killable() in virtio_request() gets killed, but looking at it
even in the code path that gets a ref the code will happily drop the ref
even before the flush is over so I guess there's no reason to actively
try to pin kernel pages...

I'd sleep better if there was a way to remove (detach?) the buffer from
the virtqueue but I can't see how to do that without breaking something
else, so I guess we'll have to live with that behavior unless someone
knows better.

-- 
Dominique Martinet | Asmadeus