CVE-2026-100236 is a High (CVSS 8.6) memory corruption flaw in the DPDK GSO library. When software GSO copies packet headers, a header longer than the segment size can cause an out-of-bounds read or write. Check your distribution or vendor advisory for a fixed package.
What's affected
The weakness is CWE-787 (out-of-bounds write). The record describes it this way: 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. A header longer than the configured GSO segment size can underflow the payload-size calculation. A remote or guest-supplied packet processed with software GSO can then trigger an out-of-bounds read or write.
The record does not list affected DPDK versions or a fixed version. Red Hat's CVE page rates the issue Important with CVSS 3.1 8.6, the same as the record, and marks the score as a draft. Red Hat's statement says environments are affected when DPDK applications use software Generic Segmentation Offload on packets from untrusted network sources or guest interfaces. Workloads that do not use software GSO, or that rely on hardware segmentation offload, are not impacted.
Red Hat's package data, when we looked, showed the grout package in Fast Datapath for RHEL 10 as affected, and several Open vSwitch packages in Fast Datapath marked will not fix. Those states change over time, so check the Red Hat page and your own vendor for the current status.
How to check if you're exposed
DPDK is usually bundled into another product, such as a virtual switch, a router or a network function. Start by listing what links DPDK in your environment.
On an RPM based host, a query like the following shows DPDK and related packages.
rpm -qa | grep -i -E 'dpdk|grout|openvswitch'
Then ask whether software GSO is enabled in the application. Vendors that ship DPDK applications can tell you whether the GSO library is used and whether it handles traffic from guests or other untrusted sources. If segmentation is done in hardware only, Red Hat says the workload is not impacted.
The free in-browser dependency scan at gold.safeguard.sh/scan can match a lockfile or manifest against known CVEs without installing anything. The Gold directory page for each CVE lists affected packages and fixes as they are published.
What to do now
- Inventory DPDK based products and the DPDK version each one ships or links.
- Read the Red Hat advisory and your own vendor advisory for fixed packages. The record gives no fixed version, so do not assume one.
- Where you cannot update yet, check whether software GSO can be turned off or replaced with hardware offload for traffic from untrusted guests or networks.
- Treat guest virtual machines on shared hosts as untrusted when assessing exposure.
- Rescan after updating and record the package versions for your change log.
Why it matters
Segmentation offload splits large payloads into packets that fit the link. Doing it in software means the library must trust packet header lengths. Here, a header longer than the segment size breaks a size calculation, so a later copy runs past its buffer. That is a classic integer underflow leading to memory corruption.
The risk is highest on data planes that serve other tenants, since a guest can hand the host a packet it did not craft by accident. The record does not mark the CVE as known exploited, and the sources we reviewed do not report exploitation.
Quick check
Does this affect every DPDK deployment?
Per Red Hat, no. It matters where software GSO processes packets from untrusted network sources or guest interfaces. Workloads without software GSO, or with hardware segmentation only, are not impacted.
Is there a fixed version I can cite?
The record does not name one, and the sources we fetched did not confirm one for upstream DPDK. Check the Red Hat advisory and your vendor for the current fixed package.
Sources
Last reviewed: 18 October 2026.
