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: <2245723.irdbgypaU6@weasel>
Date: Fri, 05 Dec 2025 14:36:41 +0100
From: Christian Schoenebeck <linux_oss@...debyte.com>
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: Matthew Wilcox <willy@...radead.org>, Chris Arges <carges@...udflare.com>,
 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)

On Friday, 5 December 2025 14:03:12 CET Dominique Martinet wrote:
> Christian Schoenebeck wrote on Fri, Dec 05, 2025 at 11:47:10AM +0100:
> > > Oh, hang on.  You're passing a kmalloc'ed page to
> > > iov_iter_get_pages_alloc().  That's not allowed ...
> > > 
> > > see
> > > https://lore.kernel.org/all/20250310142750.1209192-1-willy@infradead.org
> > > /
> > 
> > I'm confused. Looking at p9_get_mapped_pages(),
> > iov_iter_get_pages_alloc2() is only called for user space iovec data,
> > isn't it?
> 
> I think that doesn't hold true when mounting a filesystem with -o
> loop -- afaiu the kernel issues IOs to 9p from the XFS subsystem, so
> these can come from kmalloc or whatever it is they get memory with.
> 
> As to what to do with this, given Willy's last reply (thanks!), I'm
> honestly still not sure... If we can detect the pages are coming from
> somewhere we don't like I guess we can return EIO instead as a stop-gap
> measure (better than a crash)?
> If we check early enough (in client.c generic code) perhaps we could
> route these to the non-zc path that doesn't require this, so let's start
> by trying to figure out how to check what kind of page we got...?

Haven't checked yet, but shouldn't it be like this?

diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index 0b8086f58ad5..5ff4bfe25a3e 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 (iov_iter_is_iovec(data)) {
                int n;
                /*
                 * We allow only p9_max_pages pinned. We wait for the