CVE-2026-98556: gve: DQO: reject TSO packets with an out of range MSS

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.