High priorityDisclosed

Advisory · CVE-2026-100236

DPDK GSO header handling can read and write out of bounds on guest packets

A flaw in the DPDK GSO library: when software GSO copies packet headers into a new mbuf it does not check that the header fits in the source first segment or the destination buffer, and a header longer than the configured GSO segment size can underflow the payload-size calculation, so a remote or guest-supplied packet processed with software GSO can trigger an out-of-bounds read or write. Red Hat rates it CVSS 3.1 8.6.

Vendor
DPDK
Product
DPDK
Identifier / CWE
CVE-2026-100236
CWE-787
Action timing
Immediate
ELI5

Explain it like I’m five

The fast packet path trusts a header length it never checked, and a guest's packet can write outside the buffer meant to hold it.

SIMPLIFIED_ATTACK_PATH03 STEPS
  1. 01Guest or remote packet arrives

    A packet is submitted for processing with software GSO enabled.

  2. 02Header copied without a fit check

    GSO copies the packet header without verifying it fits the source segment or destination buffer, and the payload size underflows.

  3. 03Out-of-bounds access

    The copy reads or writes beyond the buffer, corrupting the data-plane process.

What happened

Red Hat disclosed CVE-2026-100236 in the DPDK GSO library, shipped in its Fast Datapath, Enterprise Linux dpdk packages, OpenShift openvswitch packages, and OpenStack. When software GSO copies packet headers into a new mbuf, it does not check that the header fits in the source first segment or in the destination buffer, and a header longer than the configured GSO segment size can underflow the payload-size calculation.

Red Hat’s bulletin lists the affected product packages. Apply the updated DPDK and Open vSwitch packages for your platform rather than relying on a version guess here.

What to do

  1. Inventory every DPDK deployment, including test, training, and individually managed instances.
  2. Apply the vendor fix or upgrade exactly as directed in the linked vendor bulletin or advisory.
  3. Restrict network access to DPDK while remediation is underway, especially for internet-facing instances.
  4. Review application and server logs for data-plane or vswitch process crashes tied to guest traffic and packets with unusually long headers.
  5. Check for accounts, content, or configuration created outside normal change processes, and rotate exposed credentials where access cannot be ruled out.
  6. Verify the deployed version or patch level after remediation.

Management note

DPDK sits under clouds and NFV: a guest-reachable memory flaw there is a host-level event. Patch hypervisor and network nodes on the accelerated ring.