LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Ido Schimmel <idosch@idosch.org>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	Shreyansh Chouhan <chouhan.shreyansh630@gmail.com>,
	davem@davemloft.net, yoshfuji@linux-ipv6.org, dsahern@kernel.org,
	kuba@kernel.org, pshelar@nicira.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	syzbot+ff8e1b9f2f36481e2efc@syzkaller.appspotmail.com
Subject: Re: [PATCH 1/2 net] ip_gre: add validation for csum_start
Date: Wed, 1 Sep 2021 09:46:48 -0400	[thread overview]
Message-ID: <CA+FuTSfTCufYmJg5Vum1Q-ndUYh+1P1hLecFht9Qd1-AdnHmaQ@mail.gmail.com> (raw)
In-Reply-To: <YS9puVgl/exGgrr3@shredder>

On Wed, Sep 1, 2021 at 7:53 AM Ido Schimmel <idosch@idosch.org> wrote:
>
> On Sat, Aug 21, 2021 at 09:41:14AM -0400, Willem de Bruijn wrote:
> > On Sat, Aug 21, 2021 at 3:14 AM Shreyansh Chouhan
> > <chouhan.shreyansh630@gmail.com> wrote:
> > >
> > > Validate csum_start in gre_handle_offloads before we call _gre_xmit so
> > > that we do not crash later when the csum_start value is used in the
> > > lco_csum function call.
> > >
> > > This patch deals with ipv4 code.
> > >
> > > Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
> > > Reported-by: syzbot+ff8e1b9f2f36481e2efc@syzkaller.appspotmail.com
> > > Signed-off-by: Shreyansh Chouhan <chouhan.shreyansh630@gmail.com>
> >
> > Reviewed-by: Willem de Bruijn <willemb@google.com>
>
> Hi Shreyansh, Willem,
>
> I bisected packet drops with a GRE tunnel to this patch. With the
> following debug patch [1], I'm getting this output [2].
>
> Tested with IPv4 underlay only, but I assume problem exists with ip6gre
> as well.
>
> Thanks
>
> [1]
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 177d26d8fb9c..cf4e13db030b 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -473,8 +473,11 @@ static void __gre_xmit(struct sk_buff *skb, struct net_device *dev,
>
>  static int gre_handle_offloads(struct sk_buff *skb, bool csum)
>  {
> -       if (csum && skb_checksum_start(skb) < skb->data)
> +       if (csum && skb_checksum_start(skb) < skb->data) {
> +               if (net_ratelimit())
> +                       skb_dump(KERN_WARNING, skb, false);
>                 return -EINVAL;
> +       }
>         return iptunnel_handle_offloads(skb, csum ? SKB_GSO_GRE_CSUM : SKB_GSO_GRE);
>  }
>
> [2]
> skb len=84 headroom=78 headlen=84 tailroom=15902
> mac=(78,0) net=(78,20) trans=98
> shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
> csum(0x0 ip_summed=0 complete_sw=0 valid=0 level=0)
> hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=32
> dev name=g1a feat=0x0x00000006401d5869
> skb linear:   00000000: 45 00 00 54 be 12 40 00 3f 01 f9 82 c0 00 02 01
> skb linear:   00000010: c0 00 02 12 08 00 fe ad 8c 39 00 01 7c 65 2f 61
> skb linear:   00000020: 00 00 00 00 f8 7d 0a 00 00 00 00 00 10 11 12 13
> skb linear:   00000030: 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23
> skb linear:   00000040: 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33
> skb linear:   00000050: 34 35 36 37

Thanks for the detailed report, Ido.

This is a gre tunnel device with csum/ocsum enabled, correct?

How was this packet generated: does it come from the local stack or is
it a custom packet injected from userspace, e.g., with a packet socket
with vnet_hdr?

The bug that this patch intended to protect against only occurs with
ip_summed == CHECKSUM_PARTIAL (3):

                        if (skb->ip_summed == CHECKSUM_PARTIAL) {
                                *(__sum16 *)ptr = csum_fold(lco_csum(skb));
                        } else {
                                skb->ip_summed = CHECKSUM_PARTIAL;
                                skb->csum_start =
skb_transport_header(skb) - skb->head;
                                skb->csum_offset = sizeof(*greh);
                        }

 So this packet would not hit that code anyway, as it has ip_summed
CHECKSUM_NONE (0), which computes the offsets manually.

Perhaps the check needs to be refined. But I'd like to also understand
how to reproduce this / how common this false positive is.

  reply	other threads:[~2021-09-01 13:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-19 14:34 [PATCH] ip_gre/ip6_gre: add check for invalid csum_start Shreyansh Chouhan
2021-08-19 16:56 ` Willem de Bruijn
2021-08-19 17:04   ` Jakub Kicinski
2021-08-21  7:14     ` [PATCH 1/2 net] ip_gre: add validation for csum_start Shreyansh Chouhan
2021-08-21 13:41       ` Willem de Bruijn
2021-09-01 11:53         ` Ido Schimmel
2021-09-01 13:46           ` Willem de Bruijn [this message]
2021-09-01 15:53             ` Ido Schimmel
2021-09-01 21:39               ` Willem de Bruijn
2021-08-22 20:30       ` patchwork-bot+netdevbpf
2021-08-21  7:14     ` [PATCH 2/2 net] ip6_gre: " Shreyansh Chouhan
2021-08-21 13:42       ` Willem de Bruijn
2021-08-21  7:18     ` [PATCH] ip_gre/ip6_gre: add check for invalid csum_start Shreyansh Chouhan
2021-08-21 13:44       ` Willem de Bruijn

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=CA+FuTSfTCufYmJg5Vum1Q-ndUYh+1P1hLecFht9Qd1-AdnHmaQ@mail.gmail.com \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=chouhan.shreyansh630@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=idosch@idosch.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pshelar@nicira.com \
    --cc=syzbot+ff8e1b9f2f36481e2efc@syzkaller.appspotmail.com \
    --cc=yoshfuji@linux-ipv6.org \
    --subject='Re: [PATCH 1/2 net] ip_gre: add validation for csum_start' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).