From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8C5CEC4332F for ; Sun, 20 Nov 2022 14:43:34 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 71D00852EA; Sun, 20 Nov 2022 15:43:32 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1668955412; bh=5wvBA07JQ4hGjmLUwAMwBoiQFbUFXsouo1M+0XjB/Ts=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=udiEi2cmms8k2Mg/x7RlmVocbIsCEffD9ZGwmTtAH7uEkkzOdfCzVNCfi9Zu4Hsiy TPdzdEY1QJHKMg/I8Dl3NFKTfS8JwqS8sD1q1zoWg267XEmZjGGmwqTKzOtFyoSpAf wXjFS2Puh3g9Segsk5xYwz9ytS+C87jxG/uCWs3lPgyQ3HrqtppP2LesTAogI4nx5e d3sGiAB3vwM9oHWaOX+nNKVbkuCl7hdgYmDEdwTLmRFRaYeVWss3Iur7aeAeWAixmR 610GnY8pGW/BH8kwC5EQDkb/C4Cp907VGdSYV2u4ykNKkla5dmSSqdwPXURH9WyVBz RShd6MDLSsngA== Received: from [127.0.0.1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 0C72D851BB; Sun, 20 Nov 2022 15:43:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1668955411; bh=5wvBA07JQ4hGjmLUwAMwBoiQFbUFXsouo1M+0XjB/Ts=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=jevilqc2Dug/GlURna4ltxjys3b97KaP9Bd+GyEfJz4p5ab7rkx77MjAZu6y5DkNV MRSP5TqV3nDG0uNfZH5juryct6t94DXz3EHNVH7Flm526n/7MxQl0SmyPcjP/bGUf0 jLvl+JJzdbqK3O1zeqtV/FLp78jtW6lFYaGVC0AHK+bDBjarMcAz2SGqe6y2POj7KE M9LdFEILMf1VN2v/UllNo+5Ku3xTFQBhVMzzoEBhMHO75Utu/sf7ZYbvbiyaR4k1g0 irF/dWmDi2j7Mgcg0kDEoFMWXCGOaTd59dHZCNntVhlltjjz/b720rcugvn7F/NS4B tEVJe92n/8NAA== Message-ID: <030344eb-e9d8-2bf9-a2c3-f124a32f323b@denx.de> Date: Sun, 20 Nov 2022 15:43:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH] Prevent buffer overflow on USB control endpoint Content-Language: en-US To: Fabio Estevam , Szymon Heidrich , Lukasz Majewski Cc: u-boot@lists.denx.de References: <20221117094847.60409-1-szymon.heidrich@gmail.com> From: Marek Vasut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean On 11/17/22 12:50, Fabio Estevam wrote: > [Adding Lukasz and Marek] > > On Thu, Nov 17, 2022 at 6:50 AM Szymon Heidrich > wrote: >> >> Assure that the control endpoint buffer of size USB_BUFSIZ (4096) >> can not be overflown during handling of USB control transfer >> requests with wLength greater than USB_BUFSIZ. >> >> Signed-off-by: Szymon Heidrich >> --- >> drivers/usb/gadget/composite.c | 11 +++++++++++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c >> index 2a309e624e..cb89f6dca9 100644 >> --- a/drivers/usb/gadget/composite.c >> +++ b/drivers/usb/gadget/composite.c >> @@ -1019,6 +1019,17 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl) >> u8 endp; >> struct usb_configuration *c; >> >> + if (w_length > USB_BUFSIZ) { >> + if (ctrl->bRequestType & USB_DIR_IN) { >> + /* Cast away the const, we are going to overwrite on purpose. */ >> + __le16 *temp = (__le16 *)&ctrl->wLength; >> + *temp = cpu_to_le16(USB_BUFSIZ); >> + w_length = USB_BUFSIZ; Won't this end up sending corrupted packets in case they are longer than USB_BUFSIZ ? Where do such long packets come from ? What is the test-case ?