CyberSecBulletin
CVE-2026-31607NVD status: Modified

Linux: Out-of-bounds Write

CVE-2026-31607 is a critical-severity out-of-bounds write vulnerability in Linux, with a CVSS 3.1 base score of 9.8 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists versions 324262c38438255bf6bdbf6342ca47c0badaab76, 973f2c250289f5bf6cc146b98aa6fdde11fe50d6, ce744264b06b97069b3722511ab355738311fee0 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.31% chance of exploitation within 30 days, which is low compared with other CVEs.

Patch this week

Critical severity: a successful attack would have severe impact.

What to do

  1. Update Linux to 324262c38438255bf6bdbf6342ca47c0badaab76 or 973f2c250289f5bf6cc146b98aa6fdde11fe50d6 or ce744264b06b97069b3722511ab355738311fee0 or 885c8591784da6314f9aa82fa460ac69f9f79e5f, whichever matches your release line, or a later version.
  2. Update Linux Kernel to 6.6.136 or 6.12.83 or 6.18.24 or 6.19.14, whichever matches your release line, or a later version.
  3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinux1325f85fa49f57df034869de430f7c302ae23109 up to, but not including, 324262c38438255bf6bdbf6342ca47c0badaab76; 1325f85fa49f57df034869de430f7c302ae23109 up to, but not including, 973f2c250289f5bf6cc146b98aa6fdde11fe50d6; 1325f85fa49f57df034869de430f7c302ae23109 up to, but not including, ce744264b06b97069b3722511ab355738311fee0; 1325f85fa49f57df034869de430f7c302ae23109 up to, but not including, 885c8591784da6314f9aa82fa460ac69f9f79e5f; 1325f85fa49f57df034869de430f7c302ae23109 up to, but not including, 8d155e2d1c4102f74f82a2bf9c016164bb0f7384; 1325f85fa49f57df034869de430f7c302ae23109 up to, but not including, 906f16a836de13fe61f49cdce2f66f2dbd14caf4; 1325f85fa49f57df034869de430f7c302ae23109 up to, but not including, ef8ebb1c637b4cfb61a9dd2e013376774ee2033b; 1325f85fa49f57df034869de430f7c302ae23109 up to, but not including, 5e1c4ece08ccdc197177631f111845a2c68eede3; and 12 more ranges324262c38438255bf6bdbf6342ca47c0badaab76, 973f2c250289f5bf6cc146b98aa6fdde11fe50d6, ce744264b06b97069b3722511ab355738311fee0, 885c8591784da6314f9aa82fa460ac69f9f79e5f, 8d155e2d1c4102f74f82a2bf9c016164bb0f7384, 906f16a836de13fe61f49cdce2f66f2dbd14caf4
Red HatRed Hat Enterprise Linux 10Not specified in the recordNot stated
Red HatRed Hat Enterprise Linux 10.0 Extended Update SupportNot specified in the recordNot stated
Red HatRed Hat Enterprise Linux 7 Extended Lifecycle SupportNot specified in the recordNot stated
Red HatRed Hat Enterprise Linux 9Not specified in the recordNot stated
Red HatRed Hat Enterprise Linux 9.6 Extended Update SupportNot specified in the recordNot stated
Red HatRed Hat Enterprise Linux 6Not specified in the recordNot stated
Red HatRed Hat Enterprise Linux 8Not specified in the recordNot stated
LinuxLinux Kernel2.6.39 up to, but not including, 6.6.136; 6.7 up to, but not including, 6.12.83; 6.13 up to, but not including, 6.18.24; 6.19 up to, but not including, 6.19.14; 7.0 up to, but not including, 7.0.16.6.136, 6.12.83, 6.18.24, 6.19.14, 7.0.1

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.

Scoring systemScoreSeverityScored by
CVSS 3.19.8CriticalCNA
CVSS 3.17.3HighCNA

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

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Out-of-bounds Write

The product writes data past the end, or before the beginning, of the intended buffer.

How developers prevent this class of flaw

  • Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples include the Safe C String Library (SafeStr) by Messier and Viega, and the Strsafe.h library from Microsoft. These libraries provide safer versions of overflow-prone string-handling functions.
  • Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND discusses canary-based detection in detail.

More Out-of-bounds Write vulnerabilities (CWE-787)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: total).
  3. Record last changed materially (score, affected products, status or references).

References

Recent Out-of-bounds Write vulnerabilities

Spotted an error? Tell us.