Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-31607 is a critical-severity Out-of-bounds Write (CWE-787) vulnerability in Linux Linux Kernel. Its CVSS base score is 9.8 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Data Obfuscation (T1001); ranked at the 22th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-31607 is a heap out-of-bounds write vulnerability in the Linux kernel's USB/IP client implementation, specifically in the usbip_pack_ret_submit() function. When processing a RET_SUBMIT response from a USB/IP server, the function unconditionally overwrites the urb->number_of_packets field with a value from the network PDU. A malicious server can supply a larger value than the original number_of_packets set during URB allocation, leading to out-of-bounds writes in usbip_recv_iso() and usbip_pad_iso() when iterating over the flexible array urb->iso_frame_desc[]. This issue was confirmed via KASAN on kernel 7.0.0-rc5, affecting systems using USB/IP for remote USB device sharing over the network.
A remote attacker controlling or compromising a USB/IP server can exploit this vulnerability against any USB/IP client connected to it, requiring no privileges, user interaction, or special conditions (CVSS 9.8: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). By crafting a RET_SUBMIT response with an inflated number_of_packets, the attacker triggers heap memory corruption beyond the allocated urb->iso_frame_desc[] region, potentially enabling arbitrary code execution, data tampering, or denial of service on the client system.
The vulnerability is addressed in Linux kernel stable releases via patches that add validation in usbip_pack_ret_submit() on the client side, comparing the response's rpdu->number_of_packets against the original urb->number_of_packets and clamping it to zero on violation to prevent the overwrite. This complements prior server-side (stub_rx.c) and gadget-side (vudc_rx.c) validations in CMD_SUBMIT paths and aligns with related hardening efforts like Kelvin Mbogo's series on receive-side integer overflow fixes. Patches are available at kernel.org stable commit hashes such as 2ab833a16a825373aad2ba7d54b572b277e95b71, 5e1c4ece08ccdc197177631f111845a2c68eede3, 885c8591784da6314f9aa82fa460ac69f9f79e5f, 8d155e2d1c4102f74f82a2bf9c016164bb0f7384, and 906f16a836de13fe61f49cdce2f66f2dbd14caf4 (CWE-787).
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-25500
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.4.1
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (including fuzzing and bounds checks) finds out-of-bounds write flaws before deployment.
Requiring documented secure-development standards and tools can mandate bounds-checked coding practices that avoid the weakness.
Secure engineering principles require explicit bounds checking and correct length calculations when performing buffer operations.
Input validation can structurally reject or sanitize data that would otherwise trigger an out-of-bounds write.
Memory-protection mechanisms limit the exploitability and blast radius of a successful out-of-bounds write.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Vulnerability scanning and recording can discover out-of-bounds write flaws so they can be remediated.
Patching or replacing vulnerable software directly eliminates known instances of this coding weakness.
Secure-development practices (static analysis, bounds checking, code review) are the primary means of preventing out-of-bounds writes.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.