All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
	edumazet@google.com, pabeni@redhat.com, stable@vger.kernel.org,
	nsz@port70.net, jasowang@redhat.com, yury.khrustalev@arm.com,
	broonie@kernel.org, sudeep.holla@arm.com,
	Willem de Bruijn <willemb@google.com>,
	stable@vger.kernel.net
Subject: Re: [PATCH net] net: tighten bad gso csum offset check in virtio_net_hdr
Date: Tue, 10 Sep 2024 03:45:18 -0400	[thread overview]
Message-ID: <20240910034415-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20240910004033.530313-1-willemdebruijn.kernel@gmail.com>

On Mon, Sep 09, 2024 at 08:38:52PM -0400, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
> 
> The referenced commit drops bad input, but has false positives.
> Tighten the check to avoid these.
> 
> The check detects illegal checksum offload requests, which produce
> csum_start/csum_off beyond end of packet after segmentation.
> 
> But it is based on two incorrect assumptions:
> 
> 1. virtio_net_hdr_to_skb with VIRTIO_NET_HDR_GSO_TCP[46] implies GSO.
> True in callers that inject into the tx path, such as tap.
> But false in callers that inject into rx, like virtio-net.
> Here, the flags indicate GRO, and CHECKSUM_UNNECESSARY or
> CHECKSUM_NONE without VIRTIO_NET_HDR_F_NEEDS_CSUM is normal.
> 
> 2. TSO requires checksum offload, i.e., ip_summed == CHECKSUM_PARTIAL.
> False, as tcp[46]_gso_segment will fix up csum_start and offset for
> all other ip_summed by calling __tcp_v4_send_check.
> 
> Because of 2, we can limit the scope of the fix to virtio_net_hdr
> that do try to set these fields, with a bogus value.
> 
> Link: https://lore.kernel.org/netdev/20240909094527.GA3048202@port70.net/
> Fixes: 89add40066f9 ("net: drop bad gso csum_start and offset in virtio_net_hdr")
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> Cc: <stable@vger.kernel.net>


Acked-by: Michael S. Tsirkin <mst@redhat.com>

But I think netdev maintainers ask contributors not to CC
stable directly.

> ---
> 
> Verified that the syzbot repro is still caught.
> 
> An equivalent alternative would be to move the check for csum_offset
> to where the csum_start check is in segmentation:
> 
> -    if (unlikely(skb_checksum_start(skb) != skb_transport_header(skb)))
> +    if (unlikely(skb_checksum_start(skb) != skb_transport_header(skb) ||
> +                 skb->csum_offset != offsetof(struct tcphdr, check)))
> 
> Cleaner, but messier stable backport.
> 
> We'll need an equivalent patch to this for VIRTIO_NET_HDR_GSO_UDP_L4.
> But that csum_offset test was in a different commit, so different
> Fixes tag.
> ---
>  include/linux/virtio_net.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> index 6c395a2600e8d..276ca543ef44d 100644
> --- a/include/linux/virtio_net.h
> +++ b/include/linux/virtio_net.h
> @@ -173,7 +173,8 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
>  			break;
>  		case SKB_GSO_TCPV4:
>  		case SKB_GSO_TCPV6:
> -			if (skb->csum_offset != offsetof(struct tcphdr, check))
> +			if (skb->ip_summed == CHECKSUM_PARTIAL &&
> +			    skb->csum_offset != offsetof(struct tcphdr, check))
>  				return -EINVAL;
>  			break;
>  		}
> -- 
> 2.46.0.598.g6f2099f65c-goog


      parent reply	other threads:[~2024-09-10  7:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-10  0:38 [PATCH net] net: tighten bad gso csum offset check in virtio_net_hdr Willem de Bruijn
2024-09-10  0:41 ` kernel test robot
2024-09-10  4:34 ` Greg KH
2024-09-10  7:45   ` Michael S. Tsirkin
2024-09-10  7:54     ` Eric Dumazet
2024-09-10 14:35   ` Willem de Bruijn
2024-09-10  6:12 ` Jason Wang
2024-09-10 14:39   ` Willem de Bruijn
2024-09-10 14:53     ` Willem de Bruijn
2024-09-11  3:41       ` Jason Wang
2024-09-10  7:45 ` Michael S. Tsirkin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240910034415-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=broonie@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jasowang@redhat.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nsz@port70.net \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.net \
    --cc=stable@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=willemb@google.com \
    --cc=willemdebruijn.kernel@gmail.com \
    --cc=yury.khrustalev@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.