CVE-2026-98556

In the Linux kernel, the following vulnerability has been resolved:

gve: DQO: reject TSO packets with an out of range MSS

gve prep tso() 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 gso size in virtio net hdr. Layer 2 forwarding does not check the MTU for GSO packets (is skb forwardable()), and gso features check() only bounds skb->len and gso segs, never gso size.

Such a packet reaches gve tx fill tso ctx desc(), which puts gso size into the mss field of the TSO context descriptor. This field is 14 bits wide, so a gso size of 16384 is silently turned into an MSS of zero.

Drop these packets from gve prep tso(), and make sure that gve features check dqo() leaves their GSO bits alone: skb segment() splits at gso size 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.