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

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

[Eric Dumazet]

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

[PATCH net 1/2] gve: fix TX drop when GSO MSS is too small for hw

[Eric Dumazet]

From: Eddie Phillips <eddiephillips@google.com>

The device has a strict requirement that the minimum MSS
(gso_size) for TSO/GSO packets must be at least 88 bytes. If a packet
below this threshold is pushed to the hardware, it can cause
hardware to silently drop the packet, leading to increased latency
and retransmissions.

Currently, this is validated too late in the transmit pipeline
(gve_prep_tso), leading to silent drops.

Fix this by moving the validation into the .ndo_features_check
callback (gve_features_check_dqo). If we detect a GSO packet with
a gso_size smaller than GVE_TX_MIN_TSO_MSS_DQO, we clear the GSO
feature flags for this packet.

Fixes: a57e5de476be ("gve: DQO: Add TX path")
Signed-off-by: Eddie Phillips <eddiephillips@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 drivers/net/ethernet/google/gve/gve_tx_dqo.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/google/gve/gve_tx_dqo.c b/drivers/net/ethernet/google/gve/gve_tx_dqo.c
index 80ab0a449ff54e3d19e9c69226949465d48dfe3f..19829b8e13de28df81bdec0c86e8356b25fe9537 100644
--- a/drivers/net/ethernet/google/gve/gve_tx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_tx_dqo.c
@@ -577,17 +577,6 @@ static int gve_prep_tso(struct sk_buff *skb)
 	int header_len;
 	int err;
 
-	/* Note: HW requires MSS (gso_size) to be <= 9728 and the total length
-	 * of the TSO to be <= 262143.
-	 *
-	 * However, we don't validate these because:
-	 * - Hypervisor enforces a limit of 9K MTU
-	 * - Kernel will not produce a TSO larger than 64k
-	 */
-
-	if (unlikely(shinfo->gso_size < GVE_TX_MIN_TSO_MSS_DQO))
-		return -1;
-
 	/* Needed because we will modify header. */
 	err = skb_cow_head(skb, 0);
 	if (err < 0)
@@ -925,6 +914,9 @@ static bool gve_can_send_tso(const struct sk_buff *skb)
 	int cur_seg_size;
 	int i;
 
+	if (unlikely(gso_size < GVE_TX_MIN_TSO_MSS_DQO))
+		return false;
+
 	cur_seg_size = skb_headlen(skb) - header_len;
 	prev_frag_size = skb_headlen(skb);
 	cur_seg_num_bufs = cur_seg_size > 0;
-- 
2.56.0.rc1.310.g51773c2048-goog

[PATCH net 2/2] gve: DQO: reject TSO packets with an out of range MSS

[Eric Dumazet]

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.

Fixes: a57e5de476be ("gve: DQO: Add TX path")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 .../net/ethernet/google/gve/gve_desc_dqo.h    |  5 ++++
 drivers/net/ethernet/google/gve/gve_tx_dqo.c  | 26 ++++++++++++++++++-
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/google/gve/gve_desc_dqo.h b/drivers/net/ethernet/google/gve/gve_desc_dqo.h
index f7786b03c7444753fb8b71c7aaf5ed37719caa1f..d2c86c8eeae2a1025fac84f55e317d1fc5b7503c 100644
--- a/drivers/net/ethernet/google/gve/gve_desc_dqo.h
+++ b/drivers/net/ethernet/google/gve/gve_desc_dqo.h
@@ -14,6 +14,11 @@
 #define GVE_TX_MAX_HDR_SIZE_DQO 255
 #define GVE_TX_MIN_TSO_MSS_DQO 88
 
+/* HW limit. This also has to fit in the 14 bits of the mss field of
+ * struct gve_tx_tso_context_desc_dqo.
+ */
+#define GVE_TX_MAX_TSO_MSS_DQO 9728
+
 #ifndef __LITTLE_ENDIAN_BITFIELD
 #error "Only little endian supported"
 #endif
diff --git a/drivers/net/ethernet/google/gve/gve_tx_dqo.c b/drivers/net/ethernet/google/gve/gve_tx_dqo.c
index 19829b8e13de28df81bdec0c86e8356b25fe9537..3e0bed9ab94a0073a1298ee76de4230cee7e3ce3 100644
--- a/drivers/net/ethernet/google/gve/gve_tx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_tx_dqo.c
@@ -577,6 +577,20 @@ static int gve_prep_tso(struct sk_buff *skb)
 	int header_len;
 	int err;
 
+	/* Note: HW requires the total length of the TSO to be <= 262143,
+	 * this is enforced by netif_set_tso_max_size().
+	 *
+	 * MSS (gso_size) can not be trusted: packets forwarded from a tap or
+	 * injected by a packet socket can carry an arbitrary value, while the
+	 * mss field of the TSO context descriptor is only 14 bits wide.
+	 *
+	 * A too big MSS is dropped here instead of being rejected from
+	 * gve_features_check_dqo(), because software segmentation would
+	 * produce packets larger than the device can send.
+	 */
+	if (unlikely(shinfo->gso_size > GVE_TX_MAX_TSO_MSS_DQO))
+		return -1;
+
 	/* Needed because we will modify header. */
 	err = skb_cow_head(skb, 0);
 	if (err < 0)
@@ -958,7 +972,17 @@ netdev_features_t gve_features_check_dqo(struct sk_buff *skb,
 					 struct net_device *dev,
 					 netdev_features_t features)
 {
-	if (skb_is_gso(skb) && !gve_can_send_tso(skb))
+	if (!skb_is_gso(skb))
+		return features;
+
+	/* Keep the GSO bits for a too big MSS, so that gve_prep_tso() drops
+	 * the packet: software segmentation would give packets larger than
+	 * the device can send.
+	 */
+	if (skb_shinfo(skb)->gso_size > GVE_TX_MAX_TSO_MSS_DQO)
+		return features;
+
+	if (!gve_can_send_tso(skb))
 		return features & ~NETIF_F_GSO_MASK;
 
 	return features;
-- 
2.56.0.rc1.310.g51773c2048-goog

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

[Harshitha Ramamurthy]

On Wed, Sep 23, 2026 at 5:42 PM Eric Dumazet <edumazet@google.com> wrote:
>
> 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

For the series:
Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>

Thanks!

>
>  .../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
>

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

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Thu, 24 Sep 2026 00:42:50 +0000 you wrote:
> 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.
> 
> [...]

Here is the summary with links:
  - [net,1/2] gve: fix TX drop when GSO MSS is too small for hw
    https://git.kernel.org/netdev/net/c/3b430ea62340
  - [net,2/2] gve: DQO: reject TSO packets with an out of range MSS
    https://git.kernel.org/netdev/net/c/296c83b5ccc8

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html