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 8EDDDC00145 for ; Mon, 12 Dec 2022 13:24:46 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 140EE84D85; Mon, 12 Dec 2022 14:24:44 +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=1670851484; bh=wvERE7VYZxnBvQldUQ5ocU59thB6lgyLnJAnGdBZOjA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=i6VA8xw18tibdtH1CoQ6eKw8nh7qGwVO+9uAHMHUsn+rrF6V4dm/GluYCy47OfDE2 JoLc2WlCsN/sjgglj004d8sZD1R6BuxM6Zq93Gxaddbrq380Y36lPQ0sHWW61RfZmQ iByPgAxcf1sHJSMOmA3yKCjmUgfnm7C4vyxrmSVv96dISE7AP/KF3sleUOv8mcNYFp z0DchZtKwOzuqBJF8KdiJsQbhbuhkfUbQ2IPk0FpMgK4ueDRTgvrLa5jVNEZfbZ99H npRkKo3IHyRJnTJVtcwp6vG9dEJrkCuiZd57BlfPd0ujzhgtzknmzdoych8o8FBJUJ OinuHZk1DL7xA== 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 CEA8A84F68; Mon, 12 Dec 2022 14:24:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1670851482; bh=wvERE7VYZxnBvQldUQ5ocU59thB6lgyLnJAnGdBZOjA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=I/iVe9OMStj0OkLBaHIEZ/orbDBVpK/RPwYdZxkeq+aD4ODOYyIWPHVA+mFjZffjo xRZfAXq7DyktAnkWKHRvoix5J/3sM6T9ief2jwpTJMipaNglMJ7dye+iCNRaPhe7Rm aAuqGASkJ5wjK/VC781hLdfOwnVPmL/8jJK6vEx9vn06QyEy0cjzho3in3HoxMGpF9 4vRcxBFqeuvB6wMVaWtY4klSXGZL/WPRQhi6uv5qNTFuH3vOJIeIvv1CqWynY30UW5 LjllUZ+ZNo0erkeCVXDa/owemEs5Ph9tuL5ed0HkyAT1OMKx+2PWs3HDqUr4ennynT lHcdPsh6ycxLQ== Message-ID: <1b2da059-6cd3-54ff-39ad-739cb6ed4c83@denx.de> Date: Mon, 12 Dec 2022 14:24:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH] Prevent buffer overflow on USB control endpoint Content-Language: en-US To: Szymon Heidrich , Fabio Estevam , Lukasz Majewski Cc: u-boot@lists.denx.de References: <20221117094847.60409-1-szymon.heidrich@gmail.com> <030344eb-e9d8-2bf9-a2c3-f124a32f323b@denx.de> <18de8ae7-fda2-ce0c-b83b-98c3af85aa9d@gmail.com> <5e6b2d2d-376a-b1b7-4826-f0c7bdfe1f65@gmail.com> <6062efed-da78-6b04-fd02-46c0590db39c@denx.de> <2ad27a1b-a84a-84c4-3e52-313c7d01f455@gmail.com> From: Marek Vasut In-Reply-To: <2ad27a1b-a84a-84c4-3e52-313c7d01f455@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 12/12/22 10:55, Szymon Heidrich wrote: > On 28/11/2022 10:27, Marek Vasut wrote: >> On 11/28/22 10:21, Szymon Heidrich wrote: >>> On 20/11/2022 16:29, Szymon Heidrich wrote: >>>> On 20/11/2022 15:43, Marek Vasut wrote: >>>>> 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 ? >>>> >>>> The USB host will not attempt to retrieve more than wLenght bytes during transfer phase. >>>> If the device would erroneously attempt to provide more data it would result in an unexpected state. >>>> In case of most implementations the buffer for endpoint 0 along with max control transfer is limited to 4096 bytes (USB_BUFSIZ for U-Boot and Linux kernel). >>>> Still according to the USB specification wLength is two bytes an the device may receive requests with wLength larger than 4096 bytes e.g. in case of a custom/malicious USB host. >>>> For example one may build libusb with MAX_CTRL_BUFFER_LENGTH altered to 0xffff and this will allow the host to send requests with wLength up to 0xffff. >>>> In this case the original implementation may result in buffer overflows as in multiple locations a value directly derived from wLength is set as the transfer phase length. >>>> With the change applied IN requests with wLength larger than USB_BUFSIZ will be trimmed to USB_BUFSIZ, otherwise the host would read wLength-USB_BUFSIZ past cdev->req->buf. >>>> I am not aware of any cases where more than USB_BUFSIZ would be provided from a buffer other than cdev->req->buf. In case I missed such case please let me know. >>> >>> Is there anything additional required from my side? >> >> Sorry for the delay, I am still processing outstanding email. > > Could you please review this patch? I have it (or rather, one outstanding reply) in the pipeline, sorry for the delay.