kernel/linux.git/drivers/usb/usbip, branch v6.18.34

usbip: validate number_of_packets in usbip_pack_ret_submit()

2026-04-22T11:22:27+00:00

commit 2ab833a16a825373aad2ba7d54b572b277e95b71 upstream. 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. Fixes: 1325f85fa49f ("staging: usbip: bugfix add number of packets for isochronous frames") Cc: stable Acked-by: Shuah Khan Signed-off-by: Nathan Rebello Link: https://patch.msgid.link/20260402085259.234-1-nathan.c.rebello@gmail.com Signed-off-by: Greg Kroah-Hartman

usbip: Fix locking bug in RT-enabled kernels

2026-01-02T11:57:01+00:00

[ Upstream commit 09bf21bf5249880f62fe759b53b14b4b52900c6c ] Interrupts are disabled before entering usb_hcd_giveback_urb(). A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be acquired with disabled interrupts. Save the interrupt status and restore it after usb_hcd_giveback_urb(). syz reported: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 rt_spin_lock+0xc7/0x2c0 kernel/locking/spinlock_rt.c:57 spin_lock include/linux/spinlock_rt.h:44 [inline] mon_bus_complete drivers/usb/mon/mon_main.c:134 [inline] mon_complete+0x5c/0x200 drivers/usb/mon/mon_main.c:147 usbmon_urb_complete include/linux/usb/hcd.h:738 [inline] __usb_hcd_giveback_urb+0x254/0x5e0 drivers/usb/core/hcd.c:1647 vhci_urb_enqueue+0xb4f/0xe70 drivers/usb/usbip/vhci_hcd.c:818 Reported-by: syzbot+205ef33a3b636b4181fb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=205ef33a3b636b4181fb Signed-off-by: Lizhi Xu Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20250916014143.1439759-1-lizhi.xu@windriver.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: vhci-hcd: Prevent suspending virtually attached devices

2025-09-25T16:52:32+00:00

The VHCI platform driver aims to forbid entering system suspend when at least one of the virtual USB ports are bound to an active USB/IP connection. However, in some cases, the detection logic doesn't work reliably, i.e. when all devices attached to the virtual root hub have been already suspended, leading to a broken suspend state, with unrecoverable resume. Ensure the virtually attached devices do not enter suspend by setting the syscore PM flag. Note this is currently limited to the client side only, since the server side doesn't implement system suspend prevention. Fixes: 04679b3489e0 ("Staging: USB/IP: add client driver") Signed-off-by: Cristian Ciocaltea Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20250902-vhci-hcd-suspend-fix-v3-1-864e4e833559@collabora.com Signed-off-by: Greg Kroah-Hartman

sysfs: treewide: switch back to attribute_group::bin_attrs

2025-06-17T08:44:15+00:00

The normal bin_attrs field can now handle const pointers. This makes the _new variant unnecessary. Switch all users back. Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20250530-sysfs-const-bin_attr-final-v3-4-724bfcf05b99@weissschuh.net Signed-off-by: Greg Kroah-Hartman

treewide, timers: Rename from_timer() to timer_container_of()

2025-06-08T07:07:37+00:00

Move this API to the canonical timer_*() namespace. [ tglx: Redone against pre rc1 ] Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com

usbip: Correct format specifier for seqnum from %d to %u

2025-01-17T11:38:01+00:00

The seqnum field in USBIP protocol is an unsigned value. So we fix the format specifier from %d to %u to correctly display the value. Signed-off-by: Xiong Nandi Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20241231161539.20192-3-xndchn@gmail.com Signed-off-by: Greg Kroah-Hartman

usbip: Fix seqnum sign extension issue in vhci_tx_urb

2025-01-17T11:38:01+00:00

The atomic_inc_return function returns an int, while priv->seqnum is an unsigned long. So we must cast the result to u32 to prevent potential sign extension and size mismatch issues. Signed-off-by: Xiong Nandi Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20241231161539.20192-2-xndchn@gmail.com Signed-off-by: Greg Kroah-Hartman

USB: Use str_enable_disable-like helpers

2025-01-15T17:28:13+00:00

Replace ternary (condition ? "enable" : "disable") syntax with helpers from string_choices.h because: 1. Simple function call with one argument is easier to read. Ternary operator has three arguments and with wrapping might lead to quite long code. 2. Is slightly shorter thus also easier to read. 3. It brings uniformity in the text - same string. 4. Allows deduping by the linker, which results in a smaller binary file. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250114-str-enable-disable-usb-v1-6-c8405df47c19@linaro.org Signed-off-by: Greg Kroah-Hartman

usbip: vudc: Constify 'struct bin_attribute'

2024-12-24T07:56:04+00:00

The sysfs core now allows instances of 'struct bin_attribute' to be moved into read-only memory. Make use of that to protect them against accidental or malicious modifications. Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20241222-sysfs-const-bin_attr-usbip-v1-1-20d611a9bfa4@weissschuh.net Signed-off-by: Greg Kroah-Hartman

usbip: Accept arbitrarily long scatter-gather list

2024-12-24T07:56:04+00:00

Fixes issue where memory will fail to be allocated for larger bulk transfers, ~1 MB or more. This occurs because userland libraries, such as libusb, send the entire USB data buffer when SG support is detected. The assumption is that the driver knows how to properly split the data up before sending it out. By hardcoding a limit, bigger transfers that exceed the SG tablesize limit of 32 will be unable to use SG. This results in an attempt to allocate contiguous pages which, unsurprisingly, will fail too and returns an ENOMEM. It looks like other drivers that support SG allow for any length of SG lists. Accepting any SG size allows the driver to properly handle large bulk transfer situations. Tested bulk read and write operations using the following devices: - Logitech Webcam Pro 9000 - USB 2.0 - SanDisk Ultra - USB 3.0 - Logitech M500s Mouse Signed-off-by: Jason Long Reviewed-by: Shuah Khan Link: https://lore.kernel.org/r/20241218161344.202637-1-jasonlongball@gmail.com Signed-off-by: Greg Kroah-Hartman