In the Linux kernel, the following vulnerability has been resolved: usbip: validate number_of_packets in usbip_pack_ret_submit() 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. Kelvin Mbogo's series ("usb: usbip: fix integer overflow in usbip_recv_iso()", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit. 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.
When a USB/IP client receives a RET_SUBMIT response, the usbip_pack_ret_submit() function unconditionally overwrites the urb->number_of_packets field with the value received from the network PDU packet without validating its correctness. This value is then used as the upper bound of a loop in usbip_recv_iso() and usbip_pad_iso() functions, which iterate over the urb->iso_frame_desc[] array — an array whose size is determined during URB allocation based on the original number_of_packets value from CMD_SUBMIT. A malicious USB/IP server can send a number_of_packets value larger than the original in its response, causing a write beyond the allocated heap region (CWE-787). The KASAN tool confirmed the vulnerability, registering a 4-byte write directly past the end of an allocated 320-byte area.
An attacker controlling a malicious USB/IP server can cause kernel memory corruption on the client system, potentially enabling arbitrary code execution in kernel context (RCE), privilege escalation, or operating system destabilization.
Apply patches available from the vendor according to references — specific fix commits have been published at: 2ab833a16a82, 5e1c4ece08cc, 885c8591784d, 8d155e2d1c41, 906f16a836de in the Linux kernel stable repository. The fix consists of validating the rpdu->number_of_packets value against the original urb->number_of_packets before overwriting; in case of violation, the value is clamped to zero.
Linux Kernel — versions indicated in vendor references (stabilization commits available at the provided git.kernel.org addresses)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HLinux Kernel
OSLinux2.6.39 – 6.6.136 (bez)6.7 – 6.12.83 (bez)6.13 – 6.18.24 (bez)6.19 – 6.19.14 (bez)7.0 – 7.0.1 (bez)
Related vulnerabilities
Type confusion w V8 (Google Chrome) — zdalne uszkodzenie sterty
Commvault Command Center – nieuwierzytelniony RCE przez path traversal w ZIP
IBM Aspera Faspex 4.4.2 Patch Level 1 and earlier could allow a remote attacker to execute arbitrary code on t...
VMware Workspace ONE Access and Identity Manager contain a remote code execution vulnerability due to server-s...
VMware Workspace One Access, Access Connector, Identity Manager, and Identity Manager Connector address have a...