[PATCH net 0/2] gve: DQO: fix handling of out of range TSO MSS

[Eric Dumazet <edumazet@google.com>]

The DQO TX path assumes that the MSS of a TSO packet is within the
range supported by the device, [88, 9728].

This holds for locally generated traffic, but not for packets coming
from a tap or from a packet socket: virtio_net_hdr_to_skb() takes
gso_size from user space and only enforces a minimum, layer 2
forwarding does not check the MTU of GSO packets, and
gso_features_check() bounds skb->len and gso_segs but never gso_size.

Patch 1, from Eddie Phillips, deals with the lower bound. It moves the
existing test out of gve_prep_tso() into gve_features_check_dqo(), so
that these packets are segmented in software instead of being dropped.

Patch 2 deals with the upper bound, which is currently not checked at
all. gve_tx_fill_tso_ctx_desc() stores gso_size into a 14 bits wide
field, so that an MSS of 16384 silently becomes zero. Falling back to
software segmentation is not an option here, because skb_segment()
splits at gso_size regardless of the MTU, and would only replace an
invalid TSO packet by non TSO packets larger than the 9728 bytes the
device supports. These packets are dropped instead.

As noted in patch 2, oversized non TSO packets can still reach the
device whenever the stack segments in software. This is not specific
to gve and is better fixed in the core, so a patch for
__is_skb_forwardable() will be sent separately for net-next.

Eddie Phillips (1):
  gve: fix TX drop when GSO MSS is too small for hw

Eric Dumazet (1):
  gve: DQO: reject TSO packets with an out of range MSS

 .../net/ethernet/google/gve/gve_desc_dqo.h    |  5 +++
 drivers/net/ethernet/google/gve/gve_tx_dqo.c  | 32 ++++++++++++++-----
 2 files changed, 29 insertions(+), 8 deletions(-)

-- 
2.56.0.rc1.310.g51773c2048-goog