[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aFhokd2CQwn_XBzJ@codewreck.org>
Date: Mon, 23 Jun 2025 05:33:21 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Eric Van Hensbergen <ericvh@...nel.org>,
Latchesar Ionkov <lucho@...kov.net>,
Christian Schoenebeck <linux_oss@...debyte.com>,
Michael Grzeschik <m.grzeschik@...gutronix.de>,
stable@...r.kernel.org, Yuhao Jiang <danisjiang@...il.com>,
security@...nel.org, v9fs@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] net/9p: Fix buffer overflow in USB transport layer
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
Powered by blists - more mailing lists