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 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.

Published: 2026-04-24 Last update: 2026-06-01 Assigner: 416baaa9-dc9f-4396-8d5f-8c081fb06d67 Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Conclusion & alert: CVE-2026-31607 is rated Moderate Risk (45.2/100): CVSS Critical severity, with low exploitation likelihood (EPSS 0.06%). Mandatory action: Review affected assets and schedule remediation.

Risk is dynamic; we continuously reassess and refresh what is shown on this page as upstream context changes.

Exploit prediction scoring system (EPSS) score for CVE-2026-31607

EPSS lead: Daily EPSS estimates relative likelihood of exploitation; percentile ranks this CVE among scored vulnerabilities (higher = more severe relative rank).

# Date Old EPSS score New EPSS score Delta (New - Old)
1 2026-04-28 0.02% 0.06% +0.04%
2 2026-04-25 0.02%

Full EPSS history (2 records total)

Common vulnerability scoring system (CVSS) metrics for CVE-2026-31607

CVSS metrics for this CVE.

Base score Version Severity Vector Exploitability Impact Score source
9.8 3.1 CRITICAL
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Click to expand
Attack vector (AV:N)
Could be attacked over the internet or any normal routed network—not just someone sitting at the machine.
Attack complexity (AC:L)
Once they can reach the bug, pulling it off is straightforward—no weird race conditions or rare setup.
Privileges required (PR:N)
No account or special rights needed—anonymous or random user is enough.
User interaction (UI:N)
Nobody has to click “OK” or open a trap file; it can work without a victim helping.
Scope (S:U)
Damage stays in the same “trust bubble” as the broken component—no big spill into unrelated systems.
Confidentiality (C:H)
Serious risk that confidential data gets exposed in a big way.
Integrity (I:H)
They could widely tamper with or forge data—trust in the data is badly hurt.
Availability (A:H)
Could take the service down hard or make it unusable for people who depend on it.
3.9 5.9 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Weakness enumeration for CVE-2026-31607

GitHub Security Advisory for CVE-2026-31607

GHSA-fcfj-3h7q-75mq · Severity: critical — In the Linux kernel, the following vulnerability has been resolved: usbip: validate...

OS Trackers for CVE-2026-31607

vendor priority summary link
debian not yet assigned CVE-2026-31607 not yet assigned priority: Debian including 1 source packages (linux), 5 status rows across 5 suites (bookworm, bullseye, forky, sid, trixie): resolved 3, open 2. https://security-tracker.debian.org/tracker/CVE-2026-31607
redhat high https://access.redhat.com/security/cve/CVE-2026-31607
suse critical https://www.suse.com/security/cve/CVE-2026-31607/
ubuntu medium CVE-2026-31607 medium priority: Ubuntu including 161 source packages (linux, linux-allwinner-5.19, …), 1449 status rows across 9 suites (bionic, focal, jammy, noble, questing, resolute, trusty, upstream, xenial): DNE 1048, ignored 173, needed 140, released 83, needs-triage 4, pending 1. https://ubuntu.com/security/CVE-2026-31607

Affected software / configurations for CVE-2026-31607

Vendor Product Version Raw CPE
linux linux_kernel >= 2.6.39, < 6.6.136 cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
linux linux_kernel >= 6.7, < 6.12.83 cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
linux linux_kernel >= 6.13, < 6.18.24 cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
linux linux_kernel >= 6.19, < 6.19.14 cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
linux linux_kernel >= 7.0, < 7.0.1 cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*

References for CVE-2026-31607

cvelogic Threat Intelligence