Overview
About vulnerability
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.
Details
- Affected product:
- AlmaLinux 9.2 ESU , CentOS 7 ELS , Oracle Linux 7 ELS , RHEL 7 ELS , TuxCare 9.6 ESU , Ubuntu 16.04 ELS , Ubuntu 18.04 ELS , Ubuntu 20.04 ELS
- Affected packages:
- linux @ 4.15.0 (+11 more)
Fixes
KernelCare state
Live-patch status from KernelCare for each operating system.
| Operating system | Status | Covered kernels |
|---|---|---|
| AlmaLinux 10 | Will Not Fix |
37 kernels
|
| AlmaLinux 9 | Released |
106 kernels
|
| AlmaLinux 9.6 ESU | Released |
9 kernels
|
| Amazon Linux 2023 | Planned | — |
| CentOS 7 | Released |
35 kernels
|
| CentOS 7 ELS | Planned | — |
| CentOS 7 plus | Released |
23 kernels
|
| Debian 11 | In Rollout |
37 kernels
|
| Debian 11 cloud | In Rollout |
17 kernels
|
| Debian 12 | Released |
40 kernels
|
| Debian 13 | Planned | — |
| Oracle Linux 10 | Will Not Fix |
35 kernels
|
| Oracle Linux 9 | Released |
109 kernels
|
| Proxmox VE 7 5.15 | Released |
47 kernels
|
| RHEL 10 | Will Not Fix |
37 kernels
|
| RHEL 7 | Released |
56 kernels
|
| RHEL 9 | Released |
104 kernels
|
| Rocky Linux 10 | Will Not Fix |
27 kernels
|
| Rocky Linux 9 | Released |
85 kernels
|
| Ubuntu 18.04 | Planned | — |
| Ubuntu 18.04 Azure | Planned | — |
| Ubuntu 18.04 GCP | Planned | — |
| Ubuntu 20.04 HWE AWS | Released |
57 kernels
|
| Ubuntu 20.04 HWE Azure | Released |
40 kernels
|
| Ubuntu 22.04 | Released |
96 kernels
|
| Ubuntu 22.04 AWS | Released |
87 kernels
|
| Ubuntu 22.04 Azure | Released |
77 kernels
|
| Ubuntu 24.04 | Planned | — |
| Ubuntu 24.04 AWS | Planned | — |