Skip to main content
VulnerabilityPublished Updated

CVE-2026-31607: Linux kernel · usbip: validate number_of_packets in usbip_pack_ret_submit()

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 9.8 Critical · fixed in ef8ebb1c637b4cfb61a9dd2e013376774ee2033b : patch Linux kernel as a priority.

Data as of 26 Oct 2026, 10:24 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.3% chance of exploitation in 30 days – higher than 23% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers can reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in ef8ebb1c637b4cfb61a9dd2e013376774ee2033b, ce744264b06b97069b3722511ab355738311fee0, 324262c38438255bf6bdbf6342ca47c0badaab76 +11
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 24 Apr 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • >=2.6.32.37 <2.6.33
  • >=2.6.33.10 <2.6.34
  • >=2.6.34.11 <2.6.35
  • >=2.6.35.13 <2.6.36
  • >=2.6.38.3 <2.6.39
Fixed in
  • ef8ebb1c637b4cfb61a9dd2e013376774ee2033b
  • ce744264b06b97069b3722511ab355738311fee0
  • 324262c38438255bf6bdbf6342ca47c0badaab76
  • 973f2c250289f5bf6cc146b98aa6fdde11fe50d6
  • 906f16a836de13fe61f49cdce2f66f2dbd14caf4
  • 885c8591784da6314f9aa82fa460ac69f9f79e5f
  • 8d155e2d1c4102f74f82a2bf9c016164bb0f7384
  • 5e1c4ece08ccdc197177631f111845a2c68eede3
  • 2ab833a16a825373aad2ba7d54b572b277e95b71
  • 2.6.39
  • 2.6.36
  • 2.6.35
  • 2.6.34
  • 2.6.33
LinuxLinuxAffected
  • =2.6.39
Fixed in–

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.

References

Community reviews

Loading reviews…