CVE-2026-31607: usbip: validate number_of_packets in usbip_pack_ret_submit()

In the Linux kernel, the following vulnerability has been resolved:

usbip: validate numberofpackets in usbippackretsubmit()

When a USB/IP client receives a RETSUBMIT response, usbippackretsubmit() unconditionally overwrites urb->numberofpackets from the network PDU. This value is subsequently used as the loop bound in usbiprecviso() and usbippadiso() to iterate over urb->isoframedesc[], a flexible array whose size was fixed at URB allocation time based on the original numberofpackets from the CMDSUBMIT.

A malicious USB/IP server can set numberofpackets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbiprecviso() writes to urb->isoframedesc[i] beyond the allocated region.

KASAN confirmed this with kernel 7.0.0-rc5:

BUG: KASAN: slab-out-of-bounds in usbiprecviso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhcirx/69

The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40)

The server side (stubrx.c) and gadget side (vudcrx.c) already validate numberofpackets in the CMDSUBMIT path since commits c6688ef9f297 ("usbip: fix stubrx: harden CMDSUBMIT path to handle malicious input") and b78d830f0049 ("usbip: fix vudcrx: harden CMDSUBMIT path to handle malicious input"). The server side validates against USBIPMAXISOPACKETS 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 numberofpackets.

This mirrors the existing validation of actuallength against transferbufferlength in usbiprecvxbuff(), which checks the response value against the original allocation size.

Kelvin Mbogo's series ("usb: usbip: fix integer overflow in usbiprecviso()", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbippackretsubmit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIPMAXISOPACKETS limit.

Fix this by checking rpdu->numberofpackets against urb->numberofpackets in usbippackretsubmit() before the overwrite. On violation, clamp to zero so that usbiprecviso() and usbippadiso() safely return early.