From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>,
Dominique Martinet <asmadeus@codewreck.org>
Cc: v9fs@lists.linux.dev, Eric Van Hensbergen <ericvh@kernel.org>,
Latchesar Ionkov <lucho@ionkov.net>,
linux-kernel@vger.kernel.org,
Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>,
Ao Wang <wangao@seu.edu.cn>, Xuewei Feng <fengxw06@126.com>,
Qi Li <qli01@tsinghua.edu.cn>, Ke Xu <xuke@tsinghua.edu.cn>,
stable@vger.kernel.org
Subject: Re: [PATCH] 9p/trans_virtio: bound RERROR copy by mapped pages
Date: Sun, 13 Sep 2026 20:09:05 +0200 [thread overview]
Message-ID: <23241140.EfDdHjke4D@weasel> (raw)
In-Reply-To: <aqZwqdnm7PW8OUv-@codewreck.org>
On Sunday, 13 September 2026 11:45:13 CEST Dominique Martinet wrote:
> Yizhou Zhao wrote on Sun, Jun 07, 2026 at 10:06:01PM +0800:
> > handle_rerror() copies the variable-length error string of a zero-copy
> > RERROR response from the receive pages into the request's static response
> > buffer. The amount copied is bounded by P9_ZC_HDR_SZ, so the data can
> > span at most two pages, but the helper is not told how many receive pages
> > were actually mapped.
> >
> > If a malicious or broken virtio 9p device reports an RERROR length that
> > exceeds the remaining bytes in the first mapped receive page, the error
> > string is treated as crossing into a second page. When only one receive
> > page was mapped, handle_rerror() still advances the page pointer and
> > dereferences the next entry, reading past the allocated in_pages array.
>
> I'm not sure that can actually happen:
> If there was an "in page" (if there wasn't this is all noop anyway and
> data was written directly to req->rc.sdata), then req->rc.size amount of
> data was received into the pages, so if it does happen to span over a
> page boundary then there are at least two pages and we don't need to
> double-check here.
>
> Christian, do you agree with me this patch is not required?
req->rc.size is coming from virtio device's used-ring len, and that is written
by 9p server, and this server-written value is not verified anywhere against
the real sizes of the descriptors that guest provided, neither by the kernel's
virtio subsystem, nor by 9p client.
So the patch's premise is: 9p server is untrusted and lying about the written
used-ring len. In that case, yes, it could crash the client.
Should you pick the patch? You can, it does fix what it claims to do, but this
is one of those project-policy / maintainer's personal opinion dependent
issues than a real-life problem fix IMHO:
- Malicious 9p server: of course server can lie about used-ring len and crash
the Linux guest this way, but server could do that anyway, at any time. This
is a virtio specific issue, 9p server is also Linux guest's host (i.e. it
fully controls guest's memory, can simply kill/shutdown at any time, same
outcome).
- Broken 9p server: that's an argument that might justify to pick the patch,
i.e. the wrong length was unintentionally written by server, everything else
server is behaving fine - very unlikely though.
P.S. Remarkable backlog processing today! :)
/Christian
prev parent reply other threads:[~2026-09-13 18:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-07 14:06 [PATCH] 9p/trans_virtio: bound RERROR copy by mapped pages Yizhou Zhao
2026-09-13 9:45 ` Dominique Martinet
2026-09-13 18:09 ` Christian Schoenebeck [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=23241140.EfDdHjke4D@weasel \
--to=linux_oss@crudebyte.com \
--cc=asmadeus@codewreck.org \
--cc=ericvh@kernel.org \
--cc=fengxw06@126.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=qli01@tsinghua.edu.cn \
--cc=stable@vger.kernel.org \
--cc=v9fs@lists.linux.dev \
--cc=wangao@seu.edu.cn \
--cc=xuke@tsinghua.edu.cn \
--cc=yangyx22@mails.tsinghua.edu.cn \
--cc=zhaoyz24@mails.tsinghua.edu.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox