From nobody Wed Apr 1 20:42:56 2026 Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2091426E706 for ; Wed, 1 Apr 2026 12:09:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.177 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775045350; cv=none; b=f94qgSSoq3Kuy4EIwtT25qZRyjvDh495nJlEPtrvdY9OKaNoF6SHPXIYitzVpwyaJoCjDK9eS5yRa81luZTnJgAWhQzkfrXaNNzQFsTwHRIKOixedjQLBa++JjasyRGhtPGLxkPtU5CAsXN8v4OpZDo4tFiHy/UZ6/G1k1ia4eY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775045350; c=relaxed/simple; bh=//Urz/K9pTwj4R51GVVhcOJ0Kf3oWTMWkp9QDOAgsFE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=nTvpvwa7XYmZY1/MBXHaFCMqfpJyHupr+pZ26WBCPv/Dgdnts4W/FldsnsWWpuZCDTkvDzr8xxtasdYy92uvD7hNR3Gk8k+Hiu3fZSs7T0OOS/85WLb3u+2+9gMKvU1rtfnSaw7+jNwr9tlNErleQEImIN0wN2h/21HA/9Xq160= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=MRLeSSci; arc=none smtp.client-ip=209.85.128.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MRLeSSci" Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-797ab169454so40450597b3.3 for ; Wed, 01 Apr 2026 05:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775045348; x=1775650148; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=gpu+nIydRNg4LqEAOn0F6sFr7pGZaX7fcnHuwE94M0Q=; b=MRLeSSciqg2O7b3M91LogUUfamZ/z0zzG9e47mxXhlA9luf2vFZzxqQm7u0ahiEaIu D8vspshsCBbsSQNtQmvzM8mNzCHStWaaoseh8j60L4QhAuO9ItHSHRk6ubywt/CYlpUr /9D9x3n6jAzxcIP3p0NyqfnuN+Ryq05pgaKSEuYJzXNfm9JB5iERWDvvxm3W7MbFPjO9 WjKemuXS9KvESywpU96B64oZ0pGiFageDRcJIQhWXjytNiahLN3a5QD04B5lFntUIM2I MSrpvHulYd+QTyZ6H4u7scMw86wjF4cpjIW9rbhD4FLxETz8XCup/P6tOwGR8EiAF0gm fSJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775045348; x=1775650148; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=gpu+nIydRNg4LqEAOn0F6sFr7pGZaX7fcnHuwE94M0Q=; b=PBk6AEoPC/BL+so1jg09umrgZMqsPRh5Hc9rxWD75GbWox+LzFdg6BfKKbCzGdrrMv IvaD1AjZHa5p6Rd9CNNNVD1nqXWoY4ySBgD4Z73LbjK9vkU2o0/uIFY2+9vDCupqNQQ2 NuG+0adU8tnqH8b7Azxb9OLpKuFUO42xYBGrg+Qy0zghq1o8CVpmezZn8/CY2UfYGi9j V5Z5xK89a/Q86lH9vg+3tMuf1h8QsQEP+d3WEKICQl5KkKTh4mgvqSxTsoJS4QVXBTgN ynR0iuToNJWm6kOPMM9arZQkyd1axKTxHPIxX9DOf6l/2o4lT7O+xjZQ2Z3nBWtCGXip iAsA== X-Forwarded-Encrypted: i=1; AJvYcCWTMYPar6SSZP9CmfNMLh7QHgRuz1yLD6Qp/fxQK96ALziU0Bk/Gk5mqpvZxfnj3FwxbgJrt5xffdM8PP8=@vger.kernel.org X-Gm-Message-State: AOJu0YxaqKXXjNEzkKjiVTk52iRROjnHlCWLLV5ESXJy1YuXKlvgkcg2 uQs7TalOF+V6pdJ3UGjC6gbga6zEORo92zTlGB85qcp6H0iebFoS2G2L X-Gm-Gg: ATEYQzwewZAMPjbsE1FyPyPaPcoF6tIwYBJ1CrP25sPjnh7MBxqRhBXtShaQ7DXN0/x lP19oFWm46LEnD9piobWAC1EQXe6jQ5WDwtZJoMns45bjz3Aic75BlGQCPWafKK9f98zoJynfLh fR684B4Mb02uBAHZcQBfQE3F+1cUja/MQUNrqiTYfbyHDMbdkRLoMJWwfvgrKICxtyOlBgHQZYu 4VOwxqxMSuiJyZbZ+7dUJ2prF1Bc8f5FRwcHCYOZJiigtWZZNvjLc9RLGQVSwb8+L0KrO6fXMqw B40xFpBxyg4RIK7EFhvo1Wh+ZKWzBJ7T8F8yC9/kBq2ER509hDmkR8B6HdEOoPEdq2Wv735ROTF Rqtg3pIuisrYpNZlLWS6MaucuoNzsAHEip+SKttBrKDPmCzdkaixRbOCfhrOUEXJRX5wKatllLq 1yAymI+Kd6E2hkuwN1NlH5CCb58LZiDEP7tI1lhgGPoHlHg1LJn/yHKTlYzvGK9T5svxyos09OP CFx X-Received: by 2002:a05:690c:388:b0:79d:dce:5880 with SMTP id 00721157ae682-7a20f4ff581mr33389067b3.7.1775045348153; Wed, 01 Apr 2026 05:09:08 -0700 (PDT) Received: from localhost.localdomain (104.194.93.216.16clouds.com. [104.194.93.216]) by smtp.gmail.com with ESMTPSA id 00721157ae682-79cb790c05asm61771647b3.16.2026.04.01.05.09.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Apr 2026 05:09:07 -0700 (PDT) From: hkbinbin To: valentina.manea.m@gmail.com, shuah@kernel.org, i@zenithal.me, gregkh@linuxfoundation.org Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, hkbinbin , stable@vger.kernel.org Subject: [PATCH] usbip: vhci: validate ret_submit number_of_packets Date: Wed, 1 Apr 2026 12:08:57 +0000 Message-ID: <20260401120857.1443552-1-hkbinbinbin@gmail.com> X-Mailer: git-send-email 2.51.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" vhci_recv_ret_submit() unpacks USBIP_RET_SUBMIT directly into the URB, including number_of_packets from the remote server. For isochronous URBs, iso_frame_desc[] was allocated using the original locally submitted number_of_packets. If a malicious or buggy USB/IP server returns a larger number_of_packets, usbip_recv_iso() will iterate past the end of urb->iso_frame_desc[] and write attacker-controlled ISO descriptors out of bounds. Later completion paths may also walk past iso_frame_desc[] if the poisoned number_of_packets is left in the URB after rejecting the response. Fix this by saving the original packet count before unpacking the PDU, rejecting larger values from the server, restoring the original count on error, and marking the connection as broken. Fixes: 1325f85fa49f ("staging: usbip: bugfix add number of packets for isoc= hronous frames") Cc: stable@vger.kernel.org Signed-off-by: hkbinbin --- drivers/usb/usbip/vhci_rx.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/drivers/usb/usbip/vhci_rx.c b/drivers/usb/usbip/vhci_rx.c index a75f4a898a41..5bbfd5ae7755 100644 --- a/drivers/usb/usbip/vhci_rx.c +++ b/drivers/usb/usbip/vhci_rx.c @@ -60,6 +60,7 @@ static void vhci_recv_ret_submit(struct vhci_device *vdev, struct usbip_device *ud =3D &vdev->ud; struct urb *urb; unsigned long flags; + int orig_number_of_packets; =20 spin_lock_irqsave(&vdev->priv_lock, flags); urb =3D pickup_urb_and_free_priv(vdev, pdu->base.seqnum); @@ -73,9 +74,33 @@ static void vhci_recv_ret_submit(struct vhci_device *vde= v, return; } =20 + /* + * Save the original number_of_packets before it gets overwritten + * by the server's response. The iso_frame_desc[] array was allocated + * based on this value, so the server must not increase it. + */ + orig_number_of_packets =3D urb->number_of_packets; + /* unpack the pdu to a urb */ usbip_pack_pdu(pdu, urb, USBIP_RET_SUBMIT, 0); =20 + /* + * Validate number_of_packets from the server response against the + * original URB allocation. A malicious server could set this to a + * larger value, causing usbip_recv_iso() to write beyond the + * iso_frame_desc[] array bounds. + */ + if (urb->number_of_packets < 0 || + urb->number_of_packets > orig_number_of_packets) { + dev_err(&urb->dev->dev, + "invalid number_of_packets in ret_submit: %d (max %d)\n", + urb->number_of_packets, orig_number_of_packets); + urb->number_of_packets =3D orig_number_of_packets; + urb->status =3D -EPROTO; + usbip_event_add(ud, VDEV_EVENT_ERROR_TCP); + goto error; + } + /* recv transfer buffer */ if (usbip_recv_xbuff(ud, urb) < 0) { urb->status =3D -EPROTO; --=20 2.51.0