linux-kernel - Re: [PATCH net v2] gve: ignore nonrelevant GSO type bits when processing TSO headers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6663143b90996_2f27b2949@willemb.c.googlers.com.notmuch>
Date: Fri, 07 Jun 2024 10:07:55 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: joshwash@...gle.com, 
 netdev@...r.kernel.org
Cc: davem@...emloft.net, 
 kuba@...nel.org, 
 stable@...nel.org, 
 Joshua Washington <joshwash@...gle.com>, 
 Praveen Kaligineedi <pkaligineedi@...gle.com>, 
 Harshitha Ramamurthy <hramamurthy@...gle.com>, 
 Willem de Bruijn <willemb@...gle.com>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Andrei Vagin <avagin@...il.com>, 
 Jeroen de Borst <jeroendb@...gle.com>, 
 Shailend Chand <shailend@...gle.com>, 
 Paolo Abeni <pabeni@...hat.com>, 
 Rushil Gupta <rushilg@...gle.com>, 
 Bailey Forrest <bcf@...gle.com>, 
 Catherine Sullivan <csully@...gle.com>, 
 open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net v2] gve: ignore nonrelevant GSO type bits when
 processing TSO headers

joshwash@ wrote:
> From: Joshua Washington <joshwash@...gle.com>
> 
> TSO currently fails when the skb's gso_type field has more than one bit
> set.
> 
> TSO packets can be passed from userspace using PF_PACKET, TUNTAP and a
> few others, using virtio_net_hdr (e.g., PACKET_VNET_HDR). This includes
> virtualization, such as QEMU, a real use-case.
> 
> The gso_type and gso_size fields as passed from userspace in
> virtio_net_hdr are not trusted blindly by the kernel. It adds gso_type
> |= SKB_GSO_DODGY to force the packet to enter the software GSO stack
> for verification.
> 
> This issue might similarly come up when the CWR bit is set in the TCP
> header for congestion control, causing the SKB_GSO_TCP_ECN gso_type bit
> to be set.
> 
> Fixes: a57e5de476be ("gve: DQO: Add TX path")
> Signed-off-by: Joshua Washington <joshwash@...gle.com>
> Reviewed-by: Praveen Kaligineedi <pkaligineedi@...gle.com>
> Reviewed-by: Harshitha Ramamurthy <hramamurthy@...gle.com>
> Reviewed-by: Willem de Bruijn <willemb@...gle.com>
> Suggested-by: Eric Dumazet <edumazet@...gle.com>
> Acked-by: Andrei Vagin <avagin@...il.com>

I did not mean to ask for a revision. When you send a v2, please do include
a changelog

> ---
>  drivers/net/ethernet/google/gve/gve_tx_dqo.c | 21 +++++---------------
>  1 file changed, 5 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/net/ethernet/google/gve/gve_tx_dqo.c b/drivers/net/ethernet/google/gve/gve_tx_dqo.c
> index fe1b26a4d736..a76b407a981b 100644
> --- a/drivers/net/ethernet/google/gve/gve_tx_dqo.c
> +++ b/drivers/net/ethernet/google/gve/gve_tx_dqo.c
> @@ -551,32 +551,21 @@ static int gve_prep_tso(struct sk_buff *skb)
>  	 * - Hypervisor enforces a limit of 9K MTU
>  	 * - Kernel will not produce a TSO larger than 64k
>  	 */
> -

Accidental removal?

>  	if (unlikely(skb_shinfo(skb)->gso_size < GVE_TX_MIN_TSO_MSS_DQO))
>  		return -1;
>  
> +	if (!(skb_shinfo(skb)->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6)))
> +		return -EINVAL;
> +