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 9670CC433FE for ; Thu, 17 Nov 2022 00:44:13 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 40C3E84FBE; Thu, 17 Nov 2022 01:44:11 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="c6bM4net"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 34D18851DA; Thu, 17 Nov 2022 01:44:10 +0100 (CET) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 955F880F1E for ; Thu, 17 Nov 2022 01:44:07 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sultanqasim@gmail.com Received: by mail-il1-x12b.google.com with SMTP id x16so189393ilm.5 for ; Wed, 16 Nov 2022 16:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:date:cc:in-reply-to:from:subject :mime-version:content-transfer-encoding:from:to:cc:subject:date :message-id:reply-to; bh=qONkUhSTELzFUHgD4i/FkTykx5yTrLnNARseUEaafK4=; b=c6bM4netseAn6btmcGHFjBhGIuRAJUZ1GeiC8UK/xNxVmpyTifq6jXurO68pUWiyZS js1HIXHIaoesWBDOX0sA8ip5ZxVWW8bp9au7aNZBQGF/0qxjYk+8CCPl6Yp3D3TE6sIX J1ODXEeuvbZMuazmfH1Ie/4LP481o3kms95UTVikAwLPec4MIJmK/Cdg8VDK3RwZrmSl I54GXCrY+aoextJXj6cuEUAlC70Ktwn70gX6feQ5Cquz3SmUS2qrMaL/fSARs7nohsAa bY4Jz0MOOxgMIwJJo8NLNFpw6Hm/UzuKM3g9VtjCKvrxEhCsFPJQdpM7UqQApfOsvag0 lyHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:date:cc:in-reply-to:from:subject :mime-version:content-transfer-encoding:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=qONkUhSTELzFUHgD4i/FkTykx5yTrLnNARseUEaafK4=; b=bF3d4+1s7c1eyaxaxwKnKqz4XT4SguA8G2vMz1saEcQSQbrKKhlQ5Crevae62OpYiw rVe9Uu5bQ/ltH90Y7FBoBO9ughouo4ZWFAiMlmi0Bz1L2cVbTImdrk8kU8htzeBkBqgI I8smEEGlY1QQ9T/0wHOnnm3dyvWo95hlc2o4J52cQJ3DuwnL/apxW7yV88e4RwPFGFEm G2vft5o3RlFcEkowKRdkvTrPND/aUYL9m/Y+NEdWRwLjE1HRjbNYUULqGrjkfXt78P0n KMevx8G8vLfD1if9Qy4SWtKZQL7QyibVHvQHMlRja+lVswSAwg6lnlaWsnD+TFqKPGB3 uSJw== X-Gm-Message-State: ANoB5pnOcCKTKUOpQpDrVChubxCaphhGUSudyZpXaPPLRbot/9jGtKGw FY7iTUSF3Zr7isVGPsD5E6ZNPrmKi2k= X-Google-Smtp-Source: AA0mqf5SDCrEZ32OmULfgJeHs8aQiv2ym8l1py4TjSZlrezCaMqnbCTkkpE0+QMiqxrY4KiH4NKB7A== X-Received: by 2002:a92:d7d1:0:b0:302:4eeb:f01e with SMTP id g17-20020a92d7d1000000b003024eebf01emr235330ilq.103.1668645845636; Wed, 16 Nov 2022 16:44:05 -0800 (PST) Received: from smtpclient.apple ([208.98.222.49]) by smtp.gmail.com with ESMTPSA id o11-20020a056638124b00b00363fe31cf55sm6368535jas.40.2022.11.16.16.44.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Nov 2022 16:44:05 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: USB Device buffer overflow From: Sultan Khan In-Reply-To: <4bf3de35-6976-2380-df2f-41ab5c0c5f3b@gmail.com> Cc: u-boot@lists.denx.de Date: Wed, 16 Nov 2022 19:43:51 -0500 Message-Id: <3910ECDA-0F38-4940-B64B-B014BC24C376@gmail.com> References: <4bf3de35-6976-2380-df2f-41ab5c0c5f3b@gmail.com> To: Szymon Heidrich X-Mailer: iPhone Mail (20B101) 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 Hello Szymon, Looks like a generalization of CVE-2022-2347 I found earlier. While both I a= nd Venkatesh Yadav Abbarapu of AMD made patches for that CVE localized to DFU= , given the presence of the same problematic pattern elsewhere, the bounds c= heck aspect of that CVE fix would perhaps be better in a centralized locatio= n like what you did here. Sultan > On Nov 16, 2022, at 6:56 PM, Szymon Heidrich w= rote: > =EF=BB=BFHello, >=20 > Similar to CVE-2021-39685 affecting the Linux kernel U-Boot is vulnerable t= o a buffer overflow > present in the USB Gadget stack. Handling of a control transfer request wi= th wLength larger than > USB_BUFSIZ (4096) may result in a buffer overflow. >=20 > The buffer for USB control endpoint is allocated in the composite_bind fun= ction implemented in > drivers/usb/gadget/composite.c. The buffer size is set to USB_BUFSIZ (4096= ) bytes. >=20 >> /* preallocate control response and buffer */ >> cdev->req =3D usb_ep_alloc_request(gadget->ep0, GFP_KERNEL); >> if (!cdev->req) >> goto fail; >> cdev->req->buf =3D memalign(CONFIG_SYS_CACHELINE_SIZE, USB_BUFSIZ); >> if (!cdev->req->buf) >> goto fail; >> cdev->req->complete =3D composite_setup_complete; >> gadget->ep0->driver_data =3D cdev; >=20 > In the composite_setup function data transfer phase is set up to the lengt= h of "value" bytes > which in multiple cases may be controlled by an attacker (is set to wLengt= h). >=20 >> if (value >=3D 0) { >> req->length =3D value; >> req->zero =3D value < w_length; >> value =3D usb_ep_queue(gadget->ep0, req, GFP_KERNEL); >> if (value < 0) { >> debug("ep_queue --> %d\n", value); >> req->status =3D 0; >> composite_setup_complete(gadget->ep0, req); >> } >> } >=20 > In example the OS descriptor handler may be forced to set value to w_lengt= h. >=20 >> } else { >> /* "extended compatibility ID"s */ >> count =3D count_ext_compat(os_desc_cfg); >> buf[8] =3D count; >> count *=3D 24; /* 24 B/ext compat desc */ >> count +=3D 16; /* header */ >> put_unaligned_le32(count, buf); >> buf +=3D 16; >> fill_ext_compat(os_desc_cfg, buf); >> value =3D w_length; >> } >=20 > Execution of this code path for wLength set to a value larger then USB_BUFS= IZ will result > in a buffer overflow. Since wLength is a double byte value it may have val= ues up to 0xffff. >=20 > Besides the common OS descriptor handler this issue may be exploited for s= ome of the available > gadgets e.g. f_dfu, f_sdp where "value" is derived from wLength. >=20 > drivers/usb/gadget/f_dfu.c >> static int handle_dnload(struct usb_gadget *gadget, u16 len) >> { >> struct usb_composite_dev *cdev =3D get_gadget_data(gadget); >> struct usb_request *req =3D cdev->req; >> struct f_dfu *f_dfu =3D req->context; >>=20 >> if (len =3D=3D 0) >> f_dfu->dfu_state =3D DFU_STATE_dfuMANIFEST_SYNC; >>=20 >> req->complete =3D dnload_request_complete; >>=20 >> return len; >> } >=20 > drivers/usb/gadget/f_sdp.c >> if (req_type =3D=3D USB_TYPE_CLASS) { >> int report =3D w_value & HID_REPORT_ID_MASK; >>=20 >> /* HID (SDP) request */ >> switch (ctrl->bRequest) { >> case HID_REQ_SET_REPORT: >> switch (report) { >> case 1: >> value =3D SDP_COMMAND_LEN + 1; >> req->complete =3D sdp_rx_command_complete; >> sdp_func->ep_int_enable =3D false; >> break; >> case 2: >> value =3D len; >> req->complete =3D sdp_rx_data_complete; >> sdp_func->state =3D SDP_STATE_RX_FILE_DATA_BUSY; >> break; >> } >> } >> } >=20 > Please find attached a patch addressing this issue. > Depending on request direction wLength larger than USB_BUFSIZ will result i= n either > endpoint stall or value trim. >=20 > Best regards, > Szymon > <0001-Prevent-buffer-overflow-on-USB-control-endpoint.patch>