From: Nathan Rebello <nathan.c.rebello@gmail.com>
To: linux-usb@vger.kernel.org
Cc: addcontent08@gmail.com, gregkh@linuxfoundation.org,
skhan@linuxfoundation.org, kyungtae.kim@dartmouth.edu
Subject: Re: [PATCH v2 1/3] usb: usbip: fix integer overflow in usbip_recv_iso()
Date: Fri, 27 Mar 2026 00:31:53 -0400 [thread overview]
Message-ID: <20260327043153.643-1-nathan.c.rebello@gmail.com> (raw)
In-Reply-To: <20260325104841.8282-1-addcontent08@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4092 bytes --]
Hi Kelvin,
Your series hardens usbip_recv_iso() and usbip_pad_iso() against
malicious number_of_packets values, but the bad value still lands in
urb->number_of_packets via usbip_pack_ret_submit() before those
checks run.
The patch below validates at the source — in usbip_pack_ret_submit()
before the overwrite — and checks against the original
urb->number_of_packets (the actual allocation bound) rather than
USBIP_MAX_ISO_PACKETS. This is a tighter check because the URB may
have been allocated for far fewer than 1024 packets.
This could complement your series as an additional layer, or stand
alone. Would be glad to rework this however the maintainers see fit —
whether folded into your series or submitted separately.
---
From: Nathan Rebello <nathan.c.rebello@gmail.com>
Subject: [PATCH] usbip: vhci: reject RET_SUBMIT with inflated
number_of_packets
When a USB/IP client receives a RET_SUBMIT response,
usbip_pack_ret_submit() unconditionally overwrites
urb->number_of_packets from the network PDU. This value is
subsequently used as the loop bound in usbip_recv_iso() and
usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible
array whose size was fixed at URB allocation time based on the
*original* number_of_packets from the CMD_SUBMIT.
A malicious USB/IP server can set number_of_packets in the response
to a value larger than what was originally submitted, causing a heap
out-of-bounds write when usbip_recv_iso() writes to
urb->iso_frame_desc[i] beyond the allocated region.
KASAN confirmed this with kernel 7.0.0-rc5:
BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640
Write of size 4 at addr ffff888106351d40 by task vhci_rx/69
The buggy address is located 0 bytes to the right of
allocated 320-byte region [ffff888106351c00, ffff888106351d40)
The server side (stub_rx.c) and gadget side (vudc_rx.c) already
validate number_of_packets in the CMD_SUBMIT path since commits
c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle
malicious input") and b78d830f0049 ("usbip: fix vudc_rx: harden
CMD_SUBMIT path to handle malicious input"). The server side validates
against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.
On the client side we have the original URB, so we can use the tighter
bound: the response must not exceed the original number_of_packets.
This mirrors the existing validation of actual_length against
transfer_buffer_length in usbip_recv_xbuff(), which checks the
response value against the original allocation size.
Fix this by checking rpdu->number_of_packets against
urb->number_of_packets in usbip_pack_ret_submit() before the
overwrite. On violation, clamp to zero so that usbip_recv_iso() and
usbip_pad_iso() safely return early.
Fixes: 0775a9cbc798 ("staging: usbip: vhci extension: modifications to the client side")
Cc: stable@vger.kernel.org
Signed-off-by: Nathan Rebello <nathan.c.rebello@gmail.com>
---
drivers/usb/usbip/usbip_common.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/usbip/usbip_common.c b/drivers/usb/usbip/usbip_common.c
--- a/drivers/usb/usbip/usbip_common.c
+++ b/drivers/usb/usbip/usbip_common.c
@@ -470,7 +470,18 @@ static void usbip_pack_ret_submit(struct usbip_header *pdu, struct urb *urb,
urb->status = rpdu->status;
urb->actual_length = rpdu->actual_length;
urb->start_frame = rpdu->start_frame;
- urb->number_of_packets = rpdu->number_of_packets;
+ /*
+ * The number_of_packets field determines the length of
+ * iso_frame_desc[], which is a flexible array allocated
+ * at URB creation time. A response must never claim more
+ * packets than originally submitted; doing so would cause
+ * an out-of-bounds write in usbip_recv_iso() and
+ * usbip_pad_iso(). Clamp to zero on violation so both
+ * functions safely return early.
+ */
+ if (rpdu->number_of_packets < 0 ||
+ rpdu->number_of_packets > urb->number_of_packets)
+ rpdu->number_of_packets = 0;
+ urb->number_of_packets = rpdu->number_of_packets;
urb->error_count = rpdu->error_count;
}
}
next prev parent reply other threads:[~2026-03-27 4:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 10:48 [PATCH v2 1/3] usb: usbip: fix integer overflow in usbip_recv_iso() Kelvin Mbogo
2026-03-25 10:48 ` [PATCH v2 2/3] usb: usbip: validate iso frame actual_length " Kelvin Mbogo
2026-03-25 10:48 ` [PATCH v2 3/3] usb: usbip: fix OOB read/write in usbip_pad_iso() Kelvin Mbogo
2026-03-27 4:31 ` Nathan Rebello [this message]
2026-03-27 6:25 ` [PATCH v2 1/3] usb: usbip: fix integer overflow in usbip_recv_iso() Greg KH
-- strict thread matches above, loose matches on Subject: below --
2026-03-25 10:36 Kelvin Mbogo
2026-03-25 10:42 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260327043153.643-1-nathan.c.rebello@gmail.com \
--to=nathan.c.rebello@gmail.com \
--cc=addcontent08@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=kyungtae.kim@dartmouth.edu \
--cc=linux-usb@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox