From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Lei YU <yulei.sh@bytedance.com>, Felipe Balbi <balbi@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>,
Henry Tian <tianxiaofeng@bytedance.com>,
Jakob Koschel <jakobkoschel@gmail.com>,
linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: gadget: aspeed: fix buffer overflow
Date: Tue, 25 Oct 2022 08:59:17 +1100 [thread overview]
Message-ID: <661b43881b7f8764919847f29c0daf1866441090.camel@kernel.crashing.org> (raw)
In-Reply-To: <20221024094853.2877441-1-yulei.sh@bytedance.com>
On Mon, 2022-10-24 at 09:48 +0000, Lei YU wrote:
> From: Henry Tian <tianxiaofeng@bytedance.com>
I wrote that driver, please CC me on further patches to it (thanks Joel
for the heads up).
> In ast_vhub_epn_handle_ack() when the received data length exceeds the
> buffer, it does not check the case and just copies to req.buf and cause
> a buffer overflow, kernel oops on this case.
.../...
Thanks ! Seems like a legit bug, however:
> diff --git a/drivers/usb/gadget/udc/aspeed-vhub/epn.c b/drivers/usb/gadget/udc/aspeed-vhub/epn.c
> index b5252880b389..56e55472daa1 100644
> --- a/drivers/usb/gadget/udc/aspeed-vhub/epn.c
> +++ b/drivers/usb/gadget/udc/aspeed-vhub/epn.c
> @@ -84,6 +84,7 @@ static void ast_vhub_epn_handle_ack(struct ast_vhub_ep *ep)
> {
> struct ast_vhub_req *req;
> unsigned int len;
> + int status = 0;
> u32 stat;
>
> /* Read EP status */
> @@ -119,9 +120,15 @@ static void ast_vhub_epn_handle_ack(struct ast_vhub_ep *ep)
> len = VHUB_EP_DMA_TX_SIZE(stat);
>
> /* If not using DMA, copy data out if needed */
> - if (!req->req.dma && !ep->epn.is_in && len)
> - memcpy(req->req.buf + req->req.actual, ep->buf, len);
> -
> + if (!req->req.dma && !ep->epn.is_in && len) {
> + if (req->req.actual + len > req->req.length) {
> + req->last_desc = 1;
> + status = -EOVERFLOW;
> + goto done;
Should we stall as well ? Should we continue receiving and just dropping the data until we have
a small packet ? Otherwise the EP could get out of sync for subsequent ones...
Additionally, I'm curious, why in this specific case is the device sending more data than
the buffer can hold ? The MTU change should have resulted in buffers being re-allocated no ?
Or did you change the MTU on the remote and not on the local device ?
Cheers,
Ben.
next prev parent reply other threads:[~2022-10-25 0:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-24 9:48 Lei YU
2022-10-24 21:59 ` Benjamin Herrenschmidt [this message]
2022-10-25 6:21 ` Lei Yu
2022-10-25 22:29 ` Benjamin Herrenschmidt
2022-10-28 6:59 ` Neal Liu
2022-10-28 7:41 ` Lei Yu
2022-10-28 9:04 ` Neal Liu
2022-10-28 9:17 ` Greg Kroah-Hartman
2022-10-28 9:55 ` Neal Liu
2022-10-28 10:45 ` Greg Kroah-Hartman
2022-12-20 10:51 ` Lei Yu
2022-12-21 2:17 ` Neal Liu
2022-12-21 2:26 ` Lei Yu
2023-06-21 12:02 ` Lei Yu
2023-06-21 15:59 ` Greg Kroah-Hartman
2023-06-25 3:07 ` [External] " Lei Yu
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=661b43881b7f8764919847f29c0daf1866441090.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=andrew@aj.id.au \
--cc=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jakobkoschel@gmail.com \
--cc=joel@jms.id.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=tianxiaofeng@bytedance.com \
--cc=yulei.sh@bytedance.com \
/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
all inboxes | Powered by JetHome®