UBUNTU-CVE-2026-98556: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: gve: DQO: reject TSO packets with an out of range MSS gvepreptso() notes that the device requires the MSS to be <= 9728, but does not enforce it, assuming the 9K MTU enforced by the hypervisor and the 64KB limit on TSO sizes are enough. This does not hold for packets that were not generated locally. A guest behind a tap, or any packet socket user, can provide an arbitrary gsosize in virtionethdr. Layer 2 forwarding does not check the MTU for GSO packets (isskbforwardable()), and gsofeaturescheck() only bounds skb->len and gsosegs, never gsosize. Such a packet reaches gvetxfilltsoctxdesc(), which puts gsosize into the mss field of the TSO context descriptor. This field is 14 bits wide, so a gsosize of 16384 is silently turned into an MSS of zero. Drop these packets from gvepreptso(), and make sure that gvefeaturescheckdqo() leaves their GSO bits alone: skbsegment() splits at gsosize regardless of the MTU, so falling back to software segmentation would give the device non TSO packets bigger than the 9728 bytes it supports. Note that the device can still be given oversized non TSO packets when the stack segments in software for other reasons, for instance after TSO has been disabled with ethtool. This is a generic issue, because the MTU check is skipped for GSO packets in the forwarding path, and is addressed separately.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In the Linux kernel gve DQO path, reject/drop TSO packets with gso_size (MSS) greater than 9728 in gve_prep_tso(), and ensure gve_features_check_dqo() leaves the packets' GSO bits unchanged so they are not software-segmented into oversized non-TSO packets.
Event History
Frequently Asked Questions
Which systems are most exposed to this issue?
Systems using the affected Ubuntu kernel packages with the gve DQO path are exposed when a guest is behind a tap interface or when a local user can send packets through a packet socket. These paths can supply an arbitrary GSO size in a virtio network header.
What packet condition triggers the vulnerable behavior?
A TSO packet with an MSS/GSO size above the device-supported limit of 9728 can reach the gve transmit path. A GSO size of 16384 is truncated when written to the 14-bit MSS field, resulting in an MSS value of zero.
Why is software segmentation not a safe fallback for these packets?
Software segmentation splits packets according to the supplied GSO size rather than the MTU. That could produce non-TSO packets larger than the 9728-byte size supported by the device.