From: Dominique Martinet <asmadeus@codewreck.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eric Van Hensbergen <ericvh@kernel.org>,
Latchesar Ionkov <lucho@ionkov.net>,
Christian Schoenebeck <linux_oss@crudebyte.com>,
Michael Grzeschik <m.grzeschik@pengutronix.de>,
stable@vger.kernel.org, Yuhao Jiang <danisjiang@gmail.com>,
security@kernel.org, v9fs@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] net/9p: Fix buffer overflow in USB transport layer
Date: Mon, 23 Jun 2025 05:33:21 +0900 [thread overview]
Message-ID: <aFhokd2CQwn_XBzJ@codewreck.org> (raw)
In-Reply-To: <2025062007-ravishing-overcrowd-7342@gregkh>
Greg Kroah-Hartman wrote on Fri, Jun 20, 2025 at 06:56:24AM +0200:
> > - memcpy(p9_rx_req->rc.sdata, req->buf, req->actual);
> > + if (req_size > p9_rx_req->rc.capacity) {
> > + dev_err(&cdev->gadget->dev,
> > + "%s received data size %u exceeds buffer capacity %zu\n",
> > + ep->name, req_size, p9_rx_req->rc.capacity);
>
> Do you want a broken device to be able to flood the kernel log? You
> might want to change this to dev_dbg() instead.
I realize I hadn't replied to this one -- I (still) consider 9p mounts
to be somewhat privileged/trusted, so I'm fine flooding kernel logs with
a broken device.
If the trust model changes (I've been askedto make 9p mountable by
non-root users... perhaps after we've caught up with syzcallers
reports but not holding my breath) then we can revisit this, but 9p IO
errors are rather badly behaved afaik (connection possibly never
recovers) so I'd rather the first error stands out.
> > - p9_rx_req->rc.size = req->actual;
> > + memcpy(p9_rx_req->rc.sdata, req->buf, req_size);
> >
> > - p9_client_cb(usb9pfs->client, p9_rx_req, REQ_STATUS_RCVD);
> > + p9_rx_req->rc.size = req_sizel;
>
> Did this code build properly?
Thanks/sorry for this one as well :/
--
Dominique
next prev parent reply other threads:[~2025-06-22 20:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 21:22 [PATCH v2] net/9p: Fix buffer overflow in USB transport layer Dominique Martinet via B4 Relay
2025-06-20 4:56 ` Greg Kroah-Hartman
2025-06-22 20:33 ` Dominique Martinet [this message]
2025-06-20 10:02 ` kernel test robot
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=aFhokd2CQwn_XBzJ@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=danisjiang@gmail.com \
--cc=ericvh@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=m.grzeschik@pengutronix.de \
--cc=security@kernel.org \
--cc=stable@vger.kernel.org \
--cc=v9fs@lists.linux.dev \
/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