Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2338192ybz; Thu, 23 Apr 2020 16:17:46 -0700 (PDT) X-Google-Smtp-Source: APiQypJJdIV9PHgtZvlyRZHQgP7FvMkhOxSUn0ThkYHhzMOfADCxbR8vgfGSTsj505lmreeuiGh4 X-Received: by 2002:a17:906:d7a2:: with SMTP id pk2mr5001191ejb.272.1587683866196; Thu, 23 Apr 2020 16:17:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587683866; cv=none; d=google.com; s=arc-20160816; b=ShuZOf02X9Xm+J52PLFMPOMZnHD7ZtJVCuAkG4CfYgRQsWxJ0p//lawp/jxyDVo8Ya L+kumXls5V2kjbCl71VRqERLWEVC8/tIu0Ktxu0RyHiU+ikUyOuSxSS9TshjjTIsEBCV QaL7PeAiF1JrPN6gS0gOMNnPlFnXdr4YZ05gqsJmhx8Qi+JFUdjsgB0LYYdkE+/YOmWc UBUYceVafdHLroX5YFb/TrnZhLcStWKmZydu93/LokNRZQUcp5JGvP2xKi92J/w2zl/A JkdoH/TGu5piHTLX2DcK+gjqrYyyvpeXOfQpoqAR7PlYTSh+UbVIAfuevjWexvXu4Cx1 sG3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=9M7h4VCXIFZ3zpswSUXFsNNMA9GQhBn+0BdBOceopYY=; b=Y3RkjbUvLS2PSKFTYjvHcOYse8zxgGBUdU5bT5qhak0JVnO4NWPNBUjCXvltHndp8Y xlYEq034Euq8z+PNxuOUZ3cmxRJ80sPeuUQJhc3JZTurMgt8vhKQsKr4cGBpTJuOu++w WK2w5KkCG6mAOK8V2KfWY8bLFERi69DrHQoBK0RKOeP4aniLCsGe1yTfb+UqREkz/CGy xbCDczFAQshx7Q3M7eYrMxGzgNrg/uIEbt/QfYrbRKIY6aWR27X0gTxMYbGRtU7Kk1K5 11T9OH940gsrd54iSqTHrE8ODHna3Df3CD1C+YgmLggfDYz+0J9eyOq3z6qX7ats0P4p wVjQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 5si1947508edy.189.2020.04.23.16.17.22; Thu, 23 Apr 2020 16:17:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729480AbgDWXOX (ORCPT + 99 others); Thu, 23 Apr 2020 19:14:23 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:49904 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728458AbgDWXGt (ORCPT ); Thu, 23 Apr 2020 19:06:49 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvU-0004i7-8S; Fri, 24 Apr 2020 00:06:36 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvR-00E6pd-HW; Fri, 24 Apr 2020 00:06:33 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Shuah Khan" , "Suwan Kim" , "Marek Marczykowski-=?UTF-8?Q?G=C3=B3recki?=" , "Greg Kroah-Hartman" Date: Fri, 24 Apr 2020 00:05:59 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 132/245] usbip: Fix error path of vhci_recv_ret_submit() In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Suwan Kim commit aabb5b833872524eaf28f52187e5987984982264 upstream. If a transaction error happens in vhci_recv_ret_submit(), event handler closes connection and changes port status to kick hub_event. Then hub tries to flush the endpoint URBs, but that causes infinite loop between usb_hub_flush_endpoint() and vhci_urb_dequeue() because "vhci_priv" in vhci_urb_dequeue() was already released by vhci_recv_ret_submit() before a transmission error occurred. Thus, vhci_urb_dequeue() terminates early and usb_hub_flush_endpoint() continuously calls vhci_urb_dequeue(). The root cause of this issue is that vhci_recv_ret_submit() terminates early without giving back URB when transaction error occurs in vhci_recv_ret_submit(). That causes the error URB to still be linked at endpoint list without “vhci_priv". So, in the case of transaction error in vhci_recv_ret_submit(), unlink URB from the endpoint, insert proper error code in urb->status and give back URB. Reported-by: Marek Marczykowski-Górecki Tested-by: Marek Marczykowski-Górecki Signed-off-by: Suwan Kim Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20191213023055.19933-3-suwan.kim027@gmail.com Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings --- drivers/staging/usbip/vhci_rx.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) --- a/drivers/staging/usbip/vhci_rx.c +++ b/drivers/staging/usbip/vhci_rx.c @@ -88,16 +88,21 @@ static void vhci_recv_ret_submit(struct usbip_pack_pdu(pdu, urb, USBIP_RET_SUBMIT, 0); /* recv transfer buffer */ - if (usbip_recv_xbuff(ud, urb) < 0) - return; + if (usbip_recv_xbuff(ud, urb) < 0) { + urb->status = -EPROTO; + goto error; + } /* recv iso_packet_descriptor */ - if (usbip_recv_iso(ud, urb) < 0) - return; + if (usbip_recv_iso(ud, urb) < 0) { + urb->status = -EPROTO; + goto error; + } /* restore the padding in iso packets */ usbip_pad_iso(ud, urb); +error: if (usbip_dbg_flag_vhci_rx) usbip_dump_urb(urb);