CVE-2026-98557 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
gve: DQO: fix header length used by gve_can_send_tso() for UDP GSO
gve_can_send_tso() computes how many buffers each segment of a GSO packet would span, and for this it needs the length of the headers that the device replicates in front of every segment.
It unconditionally uses skb_tcp_all_headers(), which reads the doff field of the TCP header. SKB_GSO_UDP_L4 packets have no TCP header: tcp_hdrlen() then reads one byte of the UDP payload, and header_len can be anything in [0, 60] instead of the transport offset plus the
eight bytes of the UDP header that gve_prep_tso() programs into the TSO context descriptor.
A wrong header length shifts all the segment boundaries computed in the loop, so the number of buffers per segment can be over or under estimated. In the first case, GSO is needlessly disabled for this packet by gve_features_check_dqo() and the stack has to segment it. In the second case, the driver hands the device a packet whose segments span more than GVE_TX_MAX_DATA_DESCS buffers.
Use the UDP header length for SKB_GSO_UDP_L4 packets, matching what gve_prep_tso() does.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The General Virtual Engine or gve network driver in the Linux kernel contains a logic error within its TCP Segmentation Offload implementation that affects UDP Large Receive Offload scenarios specifically utilizing the DQO hardware interface. The vulnerability centers on the function gve_can_send_tso which is responsible for determining whether a packet can be processed via GSO and calculating how many descriptor buffers each segment of such a packet will consume. This calculation relies heavily on an accurate determination of header lengths because the network device replicates headers in front of every segmented data chunk, requiring precise knowledge of their size to correctly partition the payload into valid buffer allocations.
The core technical flaw arises from an unconditional reliance on skb_tcp_all_headers for all GSO packet types including those identified as SKB_GSO_UDP_L4 which are UDP based rather than TCP based. When processing a UDP L4 segment, the code invokes tcp_hdrlen to retrieve header information but since there is no actual TCP header present in these packets this function reads arbitrary bytes from the beginning of the UDP payload instead. This results in an unpredictable and incorrect value for the variable representing header length ranging potentially anywhere between zero and sixty bytes rather than reflecting the true transport layer offset plus the standard eight byte size of a UDP header that gve_prep_tso correctly programs into the TSO context descriptor.
This discrepancy in calculated header length directly impacts the segmentation logic by shifting all computed segment boundaries within the processing loop leading to either an overestimation or underestimation of required buffers per segment depending on the garbage value read from memory. In cases where the erroneous calculation suggests more headers than actually exist it causes gve_features_check_dqo to incorrectly disable GSO for that specific packet forcing the kernel network stack to perform segmentation in software which degrades performance and increases CPU utilization unnecessarily as hardware offload capabilities are bypassed due to false safety checks failing validation.
Conversely when the miscalculated header length is smaller than reality it leads to a dangerous underestimation of buffer requirements causing the driver to hand over packets whose segments span more buffers than GVE_TX_MAX_DATA_DESCS allows which represents a hardware constraint violation that can result in data corruption descriptor errors or potential denial of service conditions as the device may reject malformed transmission requests or behave unpredictably when encountering out-of-bounds segment definitions.
The resolution involves modifying gve_can_send_tso to detect SKB_GSO_UDP_L4 packets and apply UDP header length calculations instead of defaulting to TCP specific heuristics thereby aligning with what gve_prep_tso already correctly implements for context descriptor programming ensuring consistent behavior across both TCP and UDP offload paths. This fix restores proper hardware acceleration capabilities while preventing potential buffer overflow conditions associated with incorrect segment boundary computations maintaining the integrity of network throughput optimization strategies employed by modern Linux networking stacks.
From a classification perspective this issue aligns with CWE-20 Improper Input Validation as it involves processing external packet data without adequate verification of expected structural formats leading to erroneous internal state calculations and also relates to CWE-190 Integer Overflow or Wraparound in the context of buffer count estimation potentially exceeding hardware limits while mapping to ATT&CK technique T1498 Network Denial of Service through resource exhaustion caused by inefficient software fallback processing due to disabled offload features.